$TitleOpacity=0 hides Text in Note on Map-View as well

ok. I am lost @mwra @eastgate.

This is way too much inside baseball for me.

Just let me know best practice – and I am fine.

Name, Title, Text … I simply don’t get it …

I think that, currently, $TitleOpacity is applied to the text thumbnail as well.

I’ll check to see if it’s practical to avoid this.

There are plenty more attributes relating to look and feel (shape, border, shadow, etc.) but these give the gist of things. The note’s title has been stored in system attribute $Name since the app launched in 2001, the use of ‘Title’ is attribute names used to refer to text windows which disappeared with the app redesign in v6 but still exist for legacy compatibility reasons. :slight_smile:

See more about the various system attributes: System Attribute List

Still can see text at "0"

Aha, I got to the bottom of my failure with @eastgate’s demo file. Setting $TitleOpacity to default made no change to the map (see my previous report), nor did editing the note in other ways. I just tried something I overlooked before, clicking the maps tab to force a full map re-draw and unlike before, now I see:

So going from opacity 100 to 0 works but going from 0 to 100 currently needs a manual bump to refresh the view. I guess an extra re-draw prompt is needed behind the curtain to avoid the later need in the future.

FWIw, the giveaway was when I duplicated the note that should show title/text but wasn’t. The duplicate presented correctly, hinting that a deeper re-draw needed calling.

In this case, calling changed() after modifying $TitleOpacity might be all that is needed.

1 Like

hi @PaulWalters

as I wrote here:

  • setting the Opacity manually does not cause the problem

Ok. Where are we now @mwra @eastgate?

Could you kindly provide us with refined formula one is supposed to use – at least for the time being – to achieve what actually jump-started this very post?

Thank you very much!

Thanks @mwra

All this I knew, already.

But while having to use $Name in order to put information in whereas changing the appearance of the Name asks for $Titlexyz like $TitleOpacity isn’t that straightforward at least to my non-programmer brain.

Do you understand me?

I think that, if $TitleOpacity is zero, the text thumbnail is also suppressed. If I recall aright, this was requested a few years back; I don’t remember the details.

I wonder, in your case, if using $DisplayExpression would suffice:

if ($Name=="untitled") {"[space]";} else {$Name;}

I’ll look into separating $TitleOpacity from the text thumbnail.

Nice. I’ll try it …

Meanwhile:

In this case, calling changed() after modifying $TitleOpacity might be all that is needed.

… is not an option anymore as suggested here?

I think calling changed() doesn’t help in this situation: Tinderbox assumes that if $TitleOpacity is zero, you don’t want the thumbnail either.

Politely I think this ‘thumbnail’ terminology might be adding to confusion. For most people the note’s text ($Text) is either visible or not. I assume reference to a thumbnail refers to how the magic happens behind the curtain. But, the users can’t see inside the app so ‘thumbnail’ doesn’t refer meaningfully to what they see.

What, I think the term ‘thumbnail’ is trying to imply is that the text is pre-rendered as an image and then the latter is drawn into note on the map. This would partly explain why—for those who might intuit otherwise, $Text displayed in a not in the map isn’t selectable/editable.

[Edit] This probably explains why changes to the (body) text display is not getting updated as expected. We aren’t changing ‘live’ text, but an embedded ‘render’ of that text. No big deal either way, but it it does make sense of some of the confusion upthread.

I see.

Background of my inquiry was this discussion.

Good point @mwra

I envision something like cmd + doubleclick open the text window that right now is

  • either to be invoked via View-Menu
  • or via opt+cmd+x

Even better, perhaps, placing a “…” on the upper right hand corner – right before the “+” (that allows for badge-asignment) – to trigger opt+cmd+x → people will click there just out of curiosity …

nice [Edit]-addendum, @mwra. I second that!

1 Like

and on the bottom of the Tinderbox-App-Edge, there could be something like a theBrain-timeline of last edited notes – easily accessible to click and edit no matter in which view one works. (Just like cmd + 7 in Text-Pane toggling Links. What a great feature!)

  1. Should this timeline take you back to “the note Dr. John Dee” or "the note John Dee in outline view?” That is, does the timeline represent simply the selection, or the entire state of the tab?

  2. Suppose we are working on Spinoza and we click the timeline entry “Leibniz”. Does this open Leibniz in the current tab, or in a new tab?

Yes, I’m using the term “thumbnail” to refer to text excerpt drawn in the Map Pane, as opposed to the text drawn in the right-hand Text Pane.

Currently, the thumbnail text is pre-rendered. To draw the Text pane requires us to draw the text of one note; to draw the Map pane requires that we typeset at least part of the text of numerous notes. In some cases, this has caused performance problems. In general, if the text in the map view shows up a few seconds late, it’s not a tragedy — indeed, we might not even notice the delay. But that also means that sometimes the text displayed in map view doesn’t reflect the latest edits.

1 Like

on 1.)
I’d conceive it as a “timeline” in the sense of a history, i.e. latest modified Notes – descendently. cf. TheBrain

on 2.)
More or less the same behaviour as for Links (cmd +7) in tinderbox:

  1. single click on one of the “timeline-recent-notes” = forecast the the notes content in an overlayed window
  2. double-clicking or dragging the note = open the note like opt+cmd+x

Something like this … to get things started.

What do you think? @eastgate