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.
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 …
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!)
-
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?
-
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:
- single click on one of the “timeline-recent-notes” = forecast the the notes content in an overlayed window
- 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
That all makes sense, and certainly to those used to Tinderbox. For those more used to simple box–and line tools I suspect the opposite holds, not least because there the text on the (map) screen is all the text there is.
It’s ironic that the linked-to thread includes Scapple, as Scapple openly admits it’s derivation as a less-capable ‘lite’ tool inspired by Tinderbox maps. I use Scapple for tasks suiting that need. However, I wonder of the ROI in re-engineering Tinderbox maps to support in-map text editing just to make Tinderbox more like [some other app].
I agree. I’m not sure I’d see the ROI on this, especially because just the right is the text pane where you can readily edit text or any other attribute.
The other problem of in-map text editing is that the text in map view is often very small. This facilitates getting more text into the available space, but it makes editing in place even more difficult.
2 Likes
The feature was actually requested long before Heptabase/Scrintal/Scapple existed. I remember the discussion in the old forum.
I’m not sure how this helps us—and in that I’m explicitly not suggesting the observation was intended unhelpfully. The old forum is gone so unless someone archived the discussion we don’t know the outcome. However, checking the closest there is to a record of known issues†, there is no record of the above topic as an issue. That would suggest that whatever discussion there was in the past, the person(s) with the problem didn’t think it worth raising as an issue/feature request.
Note that, as in this current forum, the forum a user-to-user discussion forum and not Tech Support. Unless the developer posts in the forum that than issue is explicitly noted for fixing/adoption, it is up to the user with the issue to context the developer directly to make their case. Please don’t shoot the messenger, I’m simply stating the rules of forum.
It’s always a bit depressing when people choose to misinterpret a suggestion to make a feature request as negativity. If we accept the forum rules (as above), then if we make a suggestion and find not everyone has or even understands the problem, it is an indication that some clarification is needed. this is actually best given to the developer by someone who actually understands the need. I’ve made enough feature requests to know that seemingly simplicity of desired feature doesn’t necessarily translate to simplicity; though the same can apply in reverse.
Tinderbox not operating like another app isn’t a bug: ‘normal’ app behaviour is highly subjective and coloured by the relative amount of use of app and often the order in which we first encounter them. There isn’t a right/wrong, only different. The point of the feature request mechanism is to look at the difference and whether it makes sense in Tinderbox and can even be engineered (at sensible dev cost) in the app. Those of us who aren’t developers can’t assume what is easy (again, speaking from experience of making such false assumptions in the past).
Making a feature request isn’t treated as a complaint, but an opportunity to explain the problem. Not least, from experience, it can lead to a better (implementation of the) solution once the real issue/context is understood by the developer.
This thread has figured out the scope of what user can do in the current app. I’d suggest someone who really wants the altered behaviour emails support and makes the case. What more the forum can do?
†. Notes.tbx as at v9.6.1 N.B. that TBX is only available Backstage, so can’t be shared here.
1 Like