Feature request: Nameable/Identifiable Windows

brookter · January 4, 2022, 10:52am

Hi,

I’ve searched, but haven’t found this being requested previously (or that it is possible in the current version…).

Request: It would be useful to be able to name each window in a TBX file so that they can be identified easily (both in the Window menus, and for programmatic selection – either in TBX or via third party tools such as Keyboard Maestro).

Failing that, please could each window beyond the first created be prefixed with a number so that shortcuts can be allocated to them and/or they can be easily distinguished in the Window menu?

Rationale: I use separate windows quite a lot, because I often want to see various views on the same data at the same time. Even on a smaller screen I find it more convenient to cmd-backtick through windows then trying to navigate between tabs.

There are two downsides to this approach:

The focus on a note persists across windows, rather than being specific to each window. (I know this has been raised before, but the ability to have a different note focused in each window is one of the features I still miss from TBX 5 after all these years, despite all the massive improvements that have happened since.)
If you have more than a couple of complex windows open then it can be a little confusing knowing which to switch to – you end up having to scan the tabs to see which is which.

For example, the TBX file I have open now has five windows:

A ‘data window’ with four tabs open – one per main container
An 'admin` window with four tabs open – one per Prototypes, Templates, Functions, Agents.
A ‘dashboard’ map window.
Two Text Windows for templates I’m working on to get round the problem I mentioned above of windows sharing the same focus.

The text windows get a name, which is good, but they are transient, while the three main windows (which are always open) all have the same name:

If I could name the windows (‘Data’, ‘Admin’, ‘Dashboard’) – or even if they were named 1:Journal 2022, 2:Journal etc – which would be reflected in the Windows menu, then I could use a Keyboard Maestro palette to select each window simply, rather than cycling through all five. Or I could just use the mouse (shudder) and select it from the Window menu…

Obviously, this is not a major problem – and I’ve probably spent too much time describing it – but I would find it a helpful addition. I have no idea how much development it would take, which of course is a very important consideration, but as an optional feature, I don’t think it would disadvantage users who don’t have the same workflow.

Thanks for listening…

mwra · January 4, 2022, 4:41pm

How? I ask as whilst different tabs within a window can have different (note) focus, the front/current tab of discrete windows (of the same document) must use the same focus. IOW, set a different focus in Window A, then Window B shows the same note selected, even if that note is not in scope of B’s current tab’s view.

The name in the caption bar of a single document window is the source TBX document’s filename (including the file extension). Thus, this is a window in document ‘test.tbx’:

The default name for tabs is in the form ‘[view type]:[document name minus extension]’: Thus:

Notice that there is another tab of the same name. If I select that:

… we see it has a different scope. The view’s root container’s path is shown in the breadcrumb bar.

But buy using saved tabs, it is possible to use a custom title in a tab. Thus:

[edit: corrected incorrect information]
To use customised tab labels and (descriptions) you must save the Tab in the document’s tab Gallery. If editing unsaved tags (i.e. in the current doc but not in the saved tabs list) you must click the Done button to save the edits (note: this closes the dialog!)
Here is this doc’s Gallery:

Note: you can’t edit and save the title and/or description of an unsaved tab (or not as at v9.1.0).

The suggestions all make sense. I suspect the omission of such in the current app reflects the fact that long-term users are used to opening tabs/windows as needed rather than having them all open. Indeed, the recent Gallery feature (above) goes some way toward this. But, there is a configuration disparity in what data is saved for a tab. Newer views like Attribute Browser and Hyperbolic view store configuration in a tab. Old views like Map store configurations view in attribute values of the parent container.

I’ll address the wider point in a separate post.

mwra · January 4, 2022, 4:51pm

The info in my last is relevant but doesn’t fully address the issue. I too am frequently baffled by the Window menu’s window list. I can’t turn v5 any more but ISTR it was a bit more informative.

To be clear, I’m not against the idea of naming windows (case having been made by OP). Whether the current Gallery could accommodate window and tab functionality or two differing dialogs are needed is a consideration.

Meanwhile, in the Window menu’s listing, I’d like it that the window items:

Group by document (possibly with rulers between different doc’s items)
Show Window and/or Tab saved custom label (if any)
After the label text, show an icon of view type of the window’s current tab’s view ^†

†. For non-doc window an icon-sized box with with a letter might suffice. e.g. ‘D’ Doc Settings, ‘F’ Find results, ‘I’ Get Info, ‘R’ Roadmap, etc.).

brookter · January 4, 2022, 6:34pm

Hi Mark, thanks for the detailed reply. A couple of comments…

I said:

“… I often want to see various views on the same data at the same type.”

By data I mean ‘my information’ in the loosest sense… So, when I’m developing this file, it’s useful to see

the tab with the Dashboard as outline, with key attributes in columns, with the text pane set to a specific note (e.g. an agent with children)
a ‘full-map’ window with the Dashboard as Map showing the effects in real time
text window (often more than one) with a function, stamp, or template which I can amend and watch the results in both the outline and the map.

It doesn’t have to be a map, of course: it’s useful to have the same note in two outline windows, one with the ‘Text Pane’ selected, with the other set to ‘Preview’, while a third text window has the template to change the export. (Normally this would be spread across two monitors, but I’m on the laptop…)

Tab Names:

I’ve not really explored the gallery, so thanks for the reminder to do that!

I don’t really have any ‘default tab names’, because I tend to open new tabs by right clicking on a container in the outline and ‘open in new tab’, which replaces the file name with the container name (as you can see in the screenshot). I leave the first tab as the full outline for navigation, so the filename is fine.

So tab names aren’t as much as a problem: it’s the window names which are confusing.

Thanks again for your comments!

David

mwra · January 4, 2022, 7:51pm

Note: I’ve corrected a slight miss-statement about the ability to edit the name/description of tabs as yet unsaved to the gallery.

Thanks for the feedback. If one window has a front tab that is a root-scope (i.e. whole doc) outline that a changed selection won’t result in an out of scope not. Meanwhile, if the other window is a 100% width map, there is no text selection visible. This is likely why you’ve not seen the issue described. conversely as 100% view width uses don’t crop up that often^† I overlooked that as a factor.

†. …and there’s nothing wrong with that at all, lest it appear otherwise. It’s just less mentioned here in the forums!

brookter · January 4, 2022, 8:11pm

Sorry, Mark, I’m not sure I follow – which issue haven’t I seen?

Do you mean that the shared focus means that the selection from the first window sometimes isn’t visible in the second window map/outline, even though the text pane (hidden or otherwise) persists? Yes, I’ve noticed that (it’s part of what I referred to in the original post). As I said, it’s the biggest thing I miss from the bad old days of V5…

Or am I missing something again?

mwra · January 4, 2022, 10:40pm

No that’s it. You can’t have two windows that have different text pane content. Not everyone’s problem, but frustrating for some.

_dp · August 14, 2022, 1:20pm

@brookter,
Did you find a satisfactory solution? I have three windows open, all named Workshop.tbx. I am able to navigate between them using Keyboard Maestro macros. Instead of “Select menu item”, which can’t distinguish between the windows by name, I used “Move and Click at (coordinates)”. Each macro consists of two clicks. The first drops the Window menu. The second selects the desired Workshop.tbx by position, rather than by name. This is a brittle workaround. It will break if you use a different screen or resolution. And it will select the wrong window if you change the order of the windows in Tinderbox. But if you don’t breathe the wrong way, it may serve your purpose.

[Warning: I’m a Tinderbox newbie. This may be a bad idea for reasons that I don’t understand.]

mwra · May 10, 2024, 11:17am

I’m intrigued, what is the driver for having so many windows/tabs open for the same TBX. I ask out of interest.

As windows have to share the same text pane focus, I find I generally use a second window in view-pane-only configuration for showing some other view. Even then, clicking an item in that window still shifts focus in my main work window so a second window is less useful than an extra tab in the same window.

Edit: for clarity, this question is not suggesting a viewpoint on the request for named windows. I’m just curious as to why. Also, unless one has multiple/large screens the difference of switching tab vs screen seems moot.

eastgate · May 10, 2024, 3:07pm

FWIW, the underlying issue might interest some of you.

In original Storyspace, there was either zero or one selected note. This was a property of the underlying object for the document, the Hypertext. If you want to get the selected note, you’d call GetHypertext()->GetSelectedNote().

As you might imagine, nearly every Tinderbox object calls this. It’s everywhere.

Later, Storyspace and then Tinderbox allowed you to select several notes. We did this modestly: you can still call GetSelectedNote(). In a multiple selection, there’s one selected note that is more selected than the others, and that’s the one you get from GetSelectedNote(). You can also call GetSelectedNotes() to get a list of selected notes. Again, many Tinderbox objects do this all the time.

If each window has its own selection, then either you have to ask your window for the selection, or you have to tell the Hypertext which window you’re using and the Hypertext has to keep track. This creates two headaches:

Some parts of Tinderbox, such as actions and HTML export, aren’t particularly tied to any window. If one of them needs to know about the current selection, which selection do they use? What about reading files from disk: we might need to select a note before we have a window, so now we need to write ourselves a memo and do that later. This could be solved, but it’s another opportunity to trip up.
More seriously, this means thousands of changes. They’re small, but each takes some time, and probably ought to be protected by additional unit tests. They’re not interesting changes, they won’t generate revenue, they won’t lead to research papers.

In the past, when Tinderbox has had to deal with pervasive changes on this scale, I’ve tried two things. Once, when Apple gave us no choice, we rewrote the whole thing for what amounted to a different operating system. That took two years. Some people badly miss Tinderbox 5 with its multitude of independent windows, even now. Plus, we lost peripheral and minor things (like QuickList formatting, which I only reimplemented this week!) that still need to be redone.

Other changes were handled incrementally. For example, Tinderbox 1 didn’t use Unicode at all, because Apple was still committed to WorldScript. What I did was to make it fairly easy to convert strings to Unicode, and Unicode strings to plain old strings. Newer parts of Tinderbox use Unicode proper; older parts switch to old-fashioned strings, do their work, and switch back if you need Unicode. This almost always works out, but there are unforeseen gaps and slips. I’ve only recently adapted the Parser classes to deal with 4-byte Unicode characters such as emoji, for example. It’s nice to be able to have an attribute named $позиція or to have an action set $Subtitle=“반지의 제왕”;. It’s been a lot of work, made tolerable by spreading it out.

Another of these massive transitions has been getting agents and actions (and other time-consuming work) off the main processor. That wasn’t a concern for Tinderbox 1, because people only had one processor. I tried a quick and dirty approach in Tinderbox 3 or 4; it ought not to have worked, but it worked fine for years — not least because the operating system itself wasn’t all that stable. Essentially, Tinderbox said “yes, I know if things collide, bad stuff will happen. But there’s not so much traffic, collisions aren’t all that likely, maybe we just trust things will be ok.” And they mostly were.

Time passed, machines got bigger and faster, and Tinderbox documents grew. They grew a lot after Tinderbox 6 came out, because in Tinderbox 5 you could only have an outline with ~1000 items before you hit the end of the macOS graphic universe! Then, 1000-note Tinderboxes were rare. Soon, they were everywhere. There were more agents and rules because, now Tinderbox could do that work behind the scenes. Traffic got heavy, and people started to crash more.

Cleaning that up has been really hard, because concurrency is hard, and because most of these issues began as rare, intermittent crashes that, over time, became less rare.

So, that’s why the current selection still applies to the entire document.

mwra · May 10, 2024, 4:01pm

Thanks for that useful backfill as to why what might ‘obviously’ be easy … is not. I can’t help but be reminded of Gerrard Hoffnung’s tale of Paddy the Bricklayer explaining his absence from work^†:

…
When the barrel hit the ground, it burst its bottom, allowing all the bricks to spill out.
I was now heavier than the barrel and so started down again at high speed.
Halfway down I met the barrel coming up and received severe injury to my shins.
When I hit the ground I landed on the bricks, getting several painful cuts from the sharp edges.

At this point I must have lost my presence of mind because I let go the line.
The barrel then came down, giving me another heavy blow on the head and putting me in hospital.

I respectfully request sick leave.

IOW, there is often more to events than imagined at first notice.

†. I think this is fairly true to the original. In trying to find a ‘fair copy’ of the original wording I was dismayed how many people have tried to ‘improve’ on the original, only to make it worse. The ‘please like and subscribe’ economy again: ugh!