I may have missed something. If I consider the many ways to add additional text info to a note I get the following illustrative case with 4 inputs ($Name, $Subtitle, $Caption and $HoverExpression) displayed in Map view.
I understood from aTBRef that when a hover expression is not specified, the subtitle is used instead (see following link). However, in the test case above deleting the HoverExpression and opening up Outline view does not give me the expected hover view of the subtitle.
The Outline behaviour described was introduced in v5.10. I can only assume something more recently has broken the behaviour. I’m guessing it’s a little-used feature which is why it’s not been noticed. I’ll make a report.
As I recall, displaying subtitles in outline view turned out to be unpopular. If you use lots of subtitles, the hover expressions got in the way.
I can understand the reasons why and that hover expressions get in the way in Outline view. One could still convey the useful information in subtitle in Outline mode along the lines of OmniOutliner which allows quick on/off of the subtitle in it’s equivalent of Outline (see screenshot below)
Clicking on the left icon turns the subtitle on and off (+ other keyboard based controls)
FWIW, I find using Outline+columns just as good for having some ‘extra’ info on screen per view item. It’s also usable today.
I can see that too and it works for shorter subtexts. For longer(sub)texts the OmniOutliner approach works better and can be turned on/off efficiently and quickly. Also re. implementation the inclusion of columns slows down my TB documents considerably if the list is long.
Sure, I was simply noting something you can do now. Unless you’ve very long $Name values (something I’ve leaned, out of enlightened sef-interest, is generally not useful for a host of display reasons) then simple ensure the columns used are wide enough - you may be unaware displayed column widths are not fixed; the default width is generally too narrow for textual values.
I’m not sure that, in principle, putting extra info, e.g. subtitle, up onto the outline as a secondary row, is any less of a resource drag than using a column. Of course it boils down to the implementation and the ROI of optimising the view performance for a not default option. In context, heavy column view use likely could be optimised for but likely at the cost of something else. Thus I’ve learned to toggle columns off when not using them at the present moment. A tab remembers the ‘current’ column settings whether displayed or not. Plus, indications are that consideration is being given to make such customisations storable in the future - essentially storing such config data that can then be applied to any tab.
Not that it matters particularly, but the OmniOutliner behaviour is slightly mis-described above. I only know this from assisting a user with so OmniOutliner/Tinderbox interchange work. OmniOutliner has no notion of things like Tinderbox’s $Text or $Subtitle. Rather if you add additional paragraphs to the item’s title, the second paragraph appears in slightly smaller text, as if it were a subtitle. IOW OmniOutliner’s column #1 is—in Tinderbox terms—$Name/$Subtitle/$Text all in one. We can of course make other additional columns in OmniOutliner, in which case these function akin to Tinderbox user attributes
