I’m working with two screens and have a window on each, both showing different parts of the same document. I’m editing text on my left screen, shuffling around notes on my right.
Is there a way I can make each window behave independently, so when I click a note on my left window the window on the right does not update to show the same note (and vice versa?)
In short: no! For reasons unclear, there appears to be a technical reason that whilst different tabs in the same window can hold a different selection/focus, different windows always share the same text window focus regardless of their view pane type/focus/scope.
To read note A and note B together, open one or the other as a standalone text window (select note, Cmd+Opt+X). I use this a lot when testing/tweaking exports. The latter also shows how choosing which note to open standalone can be counter=intuitive. So, if altering a template, open the template in the text window as this leaves you free to move focus in the main window and as importantly use Preview or Export panes.
The last makes the point that a text window doesn’t have the full range of Text pane function. essentially you can see the Displayed Attributes table and text. You can’t edit the title, use the link widget (drag links) or use the links pane.
Also you can open one or more text windows and ttb will remember them if closing saving the document.
HTH
In Tinderbox 1, the selected note(s) was a property of the Hypertext object, rather than the window. So, anything that knows what hypertext is belongs to can always ask “what is the selected note?” even if it doesn’t know what window is active.
All sorts of things in Tinderbox need this. Every menu item, nearly, needs to know the selected note in order to decide whether it should be enabled. There are at least 302 calls like this. Each would need to be changed.
But it’s worse, because every request for the selected note would now need to know what the pertinent window is. That means, for example, our menu item needs to know what the “active” window is. That’s not the topmost window, which might be a popover. That’s not the window with the key focus, which might be the Inspector. We need to pass the window along to the menuItem when asking it whether it ought to be enabled.
But the method that’s asking the menuItem doesn’t itself know the window. So it now needs to be informed.
So, yes, this is a probably a desirable change, but it’s a long tonne of work.
And there’s another consideration, too. A real concern in the design of Tinderbox has always been to keep the code malleable, so it remained easy to try new things. That’s important! Adding a new parameter to nearly every method would make things less malleable.
I have a sense that there might be a better way to do this. But I don’t yet know what it is.
Thanks for a nice understandable description of the underlying issue. Seeing they problem fro the app’s perspective helps make sense. Meanwhile, I find that judicious use of text windows gets round many see-more-than-one-note issues.
Thanks for a really interesting explanation of why things are the way they are; both the blessings and burdens of a long-maintained system laid bare.
This also feels like step 1 of a 12 step refactoring programme, ‘acceptance’ 