Merging and Managing Tabs in Tinderbox: A Quick Demo

Hi everyone,

following up on today’s meetup session, I’ve put together a short GIF that demonstrates how to work with tabs in Tinderbox.

In the GIF, you can see:

  • How separate tabs can be merged again using the Merge function. (I’m not sure whether this is an exclusive Tinderbox feature or also available in other apps on macOS 26 Tahoe. Maybe Mark @eastgate and Mark @mwra can comment on this.)
  • How this works both for the large windows and for the function we revisited today that brings individual notes back from memory.
  • That everything behaves exactly as we had hoped in the session.

In addition, two small but very useful tricks:

  • Detach tabs via drag and drop: You can pull a tab out of the current window with the mouse to create a separate window.
  • Create a tabbed group from multiple notes: When you select several notes and press Option + Command + X, Tinderbox shows these as a tabbed group.

KEY CONFIGURATION (update @satikusala):
For this to work, in macOS Desktop & Docs settings, you need to set the “Prefer tabs…” setting to “Always”.

The GIF should make these steps easy to follow at a glance.

Perhaps this is of interest to some of you …

update:
@echuck, @satikusala

  • It seems to be a “new”!? macOS feature, as it is available not only in Tinderbox but also, for example, in Safari: Menu: Window → Merge all Windows

Cheers,
andreas

251214 Merging Tabs in Tinderbox

1 Like

[My apologies, I’ve not had the spare time to watch the meet-up recording and so it’s not entirely clear what problem is being solved with all the tab split/merge.]

I generally leave the OS level tabs (and app toolbar) hidden as the extra UI steals screen space. I can see that if only using one small screen, e.g. a laptop, having all open TBXs/windows as clickable targets in the current window could be useful when doing something like comparing two documents.

It’s important to understand there are two different types of tabs here. One set is part of the app’s design and the others come for free as part of using Apple code frame-works. The later set are what I term ‘OS-level’ and essentially are per-document window tabs, noting (see further below) that stand-alone windows are ignored in such tabs.

So, these are the tabs implemented:

  • inside a document window, that therefore must belong to the same TBX
  • an-OS level document tab bar for document windows, either from the same or different open TBXs. This toolbar is hidden by default.

The ‘merge’ described merges document windows which are then displayed as a tab bar but aren’t really tabs as we think of them inside the App. Tabs within a document window cannot be merged. By clicking on the OS-level document tab and dragging that window shrinks and can then be drop-merged with another window or dropped on the background as a new discrete window.

If the secondary (OS-level) document tab bar is displayed—noting that this can be shown-hidden per window—then the OS-level document tab bar can be used to separate/merge separate windows. The 'merge command (menu WindowMerge All Windows) will merge every discrete document window into a single OS-level window with each document window as a tab on the upper, OS-level bar. If the OS-level document tab bar is not showing currently, it will be shown on the resulting merged window.

In-window tabs, i.e. the ones with a view and text pane cannot be merged either view menu command and drag dropped. A selected document tab can be separated as a new single-tab window by dragging the tab itself vertically (up or down). Horizontal drags are interpreted as an intent to reorder the tabs within the current document window.

Within their own tab bar either/both OS and app tabs can be re-ordered by dragging a tab horizontally.

I cannot reproduce the described behaviour in v11.0.1 (the current release). Following the instructions above:

  • in the current tab’s view I select several notes (I used 3)
  • I then use ⌘+⌥+X
  • I get three stand-alone note windows, not a group.

Was the right shortcut given above?

FWIW, I also tried multi-selecting the stand-alone windows—you can’t! It turns out you can show an OS-level tab bar on a stand-alone text window, but to no real effect. The ‘Merge all..’ option is greyed out and doing the merge from the context of a document window ignores any stand-alone text windows.

The key requirement is to go to System Settings:Desktop & Dock:Windows:. Set Prefer tabs when opening documents to Always; I believe the default setting is in Full Screen.

I have not liked these tabs in the past, but opening multiple text windows as a tabbed set does have real appeal.

Presumably this also means having to have both tab bars open in-app?

I’m still struggling a bit to write a clear answer for “why would I need this?” (i.e. OS-level tabs). I can understand that those use to it in other apps will have a different starting perspective. For a Tinderbox user, and new to the feature, it seems this can be helpful if using a single (small) screen and multiple windows (albeit trading off visible space for app info). Then again, stand-alone windows came back in v6/7 after the one-window design some users voted for so vocally proved a poor design constraint for a tool of Tinderbox’s type.

The problem observed here more often the reverse: seeing more than one view or at the same time. I presume with the above OS setting one would have to un-dock app windows in order to see them side by side, but—does the OS setting then re-aggregate them (as per system settings)?

Remember Ted Nelson at Tinderbox weekend? Ted really dislikes interfaces with lots of untethered windows, like Tinderbox 5 had.

So, you might like to have a bunch of text windows open simultaneously, but you don’t want each to have its own frame and title bar, and to require its own positioning. This gathers them all together in a single, separate frame.

I think it’s a niche need, but I can imagine it being handy on occasion.

2 Likes

I just updated the instructions:
KEY CONFIGURATION (update @satikusala):
For this to work, in macOS Desktop & Docs settings, you need to set the “Prefer tabs…” setting to “Always”.

1 Like

Most useful. That’s helpful, my aim is to give people a reason to try something rather than pass. For me, a delight of Tinderbox is to have so many ways to interact with my text, even if I only ever user a few at a time. :slight_smile:

I’ve made note-to-self to enhance my aTbRef notes on this subject.

Many thanks.

Were do we find v.11.1.0, @mwra?

Sorry, fat fingered typing.

As I type v11.0.1 is the public release (and what I was using for the test above).

I’ll fix the post above.

1 Like

:white_check_mark:. Done in the source TBX

The updated content will be in the refresh alongside the next public release when it comes. I’ve also moved the article on OS-level tabs out of the container of document window features as the former are about such windows not a property of them. The OS settings for allowing grouping of text windows is documented.

†. Why not now? Because i’ve had to move some articles around and rename them so it isn’t as simple as just uploading a single amended article.

1 Like

Clarifying the Original Intent

Thank you all for the valuable feedback on my initial post about Merging and Managing Tabs in Tinderbox. I’d like to take a moment to clarify what I was originally trying to highlight, especially given the thoughtful responses that have come in.

The Core Idea

My main point was about Tinderbox as a tool for thinking with notes, not just storing them. The ability to open individual notes in separate windows (using Command+Option+X) is a feature that’s been around for a long time, yet I feel it’s underutilized in many workflows.

What makes this powerful is the ability to work across container boundaries. When you’re in the middle of a thought process—capturing, editing, creating, connecting, or integrating existing materials—having quick access to specific notes in separate windows means you can make those small updates that would otherwise be forgotten. It’s about reducing friction in the moment of thinking.

The Desktop Management Aspect

Of course, this approach only works if your workspace doesn’t become cluttered. That’s why knowing how to merge windows back together is equally important. The Merge All Windows function (which appears to be implemented at the OS level) is the key tool here. It works both for individual note windows and for main document windows.

This was the focus of our meetup session on December 14, 2025, which Michael Becker kindly made available quickly – 1. Link to the whole Session and 2. Link to the demonstration of tabbed group in Tinderbox. The session was part of our new “category” on Tinderbox best practices—looking at how long-standing, low-level features can profoundly support our thinking processes when used intentionally.

Why This Matters

In the spirit of “free thinking,” this isn’t just about technical capability—it’s about creating a workspace that supports the flow of ideas. The ability to have notes visible when you need them, and to clean up when you don’t, is a small but significant part of building a sustainable note-taking practice in Tinderbox.

I hope this clarifies the original intent. I’m grateful for the discussion this has sparked and look forward to hearing more about how others approach similar challenges in their own workflows.

1 Like

Thanks for that. :slight_smile:

This confused me until I realised a likely unstated assumption that the user is using only Map view, because it is container-scope. In a map you can see all the items in the parent container and some children via container/agent viewports. Only Table view is also completely container-scoped.

By comparison, Outline / Chart/ Timeline / Treemap / Hyperbolic / Information City views, and to an extent, Attribute Browser & Crosstabs views do not have that limitation.

In what context? Here I think screen size and number of screens is a factor. I don’t experience clutter as I put windows where I want them and thus expect them to be, though I have the relative luxury of 2 x 24" and 1 x 14" on which to spread out my work. When mobile, with only 1 x 14" then toggling between windows becomes more of a UX constraint (though not the app’s fault!).

There is no implicit better/worse judgement here, but I’m not sure one context describes all uses. The way I’ve summarised this for the next aTbRef update is:

Why use this toolbar?

As noted, it is off (hidden) by default. This is because most users likely have no immediate need. however, it is built-in to current Apple frameworks so it is useful for a number of scenarios:

  • Some users dislike have a large number of discrete windows for a single app. This tool bar—and the optional OS setting (above)—allows such windows to be collected together.
  • On a single/small screen, it may be impractical to display multiple windows at the same time, so grouping this way may make it easier to switch between open Tinderbox windows.

There is no presumption of a ‘best’ setting here. It is whatever best suits a user’s equipment and style of work.

As has been noted, grouping non-document windows, e.g. Text windows, is not possible without changing an OS-level setting (I’ve documented that setting for the next release of aTbRef—see above).

Of course if other windows are in the current window toolbar, we can select them at the risk of that latter content replacing our current context. For technical reasons @eastgate has explained (and embarrassingly I can’t hold in mind) it is possible for two document windows for the same TBX to have a different current view/scope, they must all have the same selection (even if note in scope of the current view. Stand-alone text windows route around this. Indeed, if not working in Map view it is easy to locate a note and open it as a stand-alone window.

Ironically, under the old pre-v6 app model we did not have such constraints (though I think the v5’x app was probably current at the Tinderbox meet-up with Ted Nelson that @eastgate refers to above.

At that, I mainly remember being gently schooled all day by Ted, politely but firmly—like an exasperated parent, that pretty much all my views relating to information were … wrong. :open_mouth:

Bottom line, all this makes me wonder if the missing piece here isn’t a (new) method to open a different note from the current selection as a stand-alone window, I guess via a prompt dialog. If you could easily open notes not on the current map opening and merging the windows would become less necessary.

To close, please don’t anyone read this as negative towards the last post above. I just sense there’s a more fundamental answer to be unearthed.

†. I think it revolves around the fact that otherwise you end up with confusion as to what the current selection (this) is. To our human eye, this is obviously the thing we are looking at, i.e. that background app window we are looking on a non-active screen. But, how does the application know or indeed guess that intent? This, one selection for all document windows it is, as a reasonable pragmatic constraint. (I’m happy to stand corrected on this (mis-?)statement of the background.)

‡. Consider the path-matching tree shown when using the zip-method to make a text link. The same form of auto-complete might help quickly find a target note to then open as stand-alone.

Mark,

Thank you for the careful and candid engagement — and also for explicitly signalling that you suspect “a more fundamental answer” may be the right direction. I agree with that diagnosis, and I would like to restate the underlying aim as plainly as possible.

1) The point is not tab mechanics; it is continuity of thought

My original post was a report from the meet‑up session, illustrated by a GIF, and it intentionally stayed close to observable behaviour (split, merge, detach, and the macOS “Prefer tabs … Always” prerequisite). The motive for posting it was pragmatic: make it easy for others to reproduce the steps quickly and reliably, and reduce “window clutter anxiety” by showing a clean way back from multiple windows. That was the surface topic.

The reason I care is the deeper topic: Tinderbox as a tool for thinking with notes, and specifically the ability to keep a thinking process moving while making small edits and connections that would otherwise be lost to friction. In other words, the window/tab behaviour is only instrumental: it exists to serve the thinking flow, not to become a separate activity in its own right.

2) “Across container boundaries”: not a Map‑only assumption, but a working‑set need

You wrote that my phrase “across container boundaries” sounded like an unstated assumption of Map view and container‑scoped work. That is a reasonable inference, and I appreciate the clarification about which views are container‑scoped and which are not.

However, my use of “across container boundaries” was not meant as a statement about which view I use, or as a claim that other views cannot solve the problem. It was meant to name a very concrete cognitive situation:

  • I am in the middle of a thought process.
  • I realise that some other note (which is not conveniently “right here” in the current context) needs a small change, a link, a tag, an attribute update, or a quick annotation.
  • The main risk is not that Tinderbox cannot do this, but that the detour required to locate and edit that note breaks the momentum and I never return to the original thought thread.

The “separate note window” pattern is one way to maintain a stable working set in front of me while I keep moving. If there are better ways — especially view‑native ways — I am genuinely interested in those. But the requirement stays the same: protect the continuity of thought.

3) The “tabbed group” aspect is a means to protect the thinking flow

What I was trying to point to with the “tabbed group” idea is not a preference for tabs as such, but the cognitive effect of having several relevant notes gathered into one stable, compact working set.

In the middle of a thought process, the problem is often not “finding a note” in principle, but keeping multiple notes simultaneously available without constant context switching. A tabbed group (if it behaves as expected) is useful precisely because it:

  • keeps several notes co-located in one place, rather than scattered across the desktop,
  • allows fast switching within the same window, which reduces the “navigation tax,”
  • makes it more realistic to keep a small constellation of notes open long enough to actually work the thought through (capture → edit → connect → integrate), instead of interrupting the process to manage windows.

So, the substantive point is: tabbed grouping is valuable insofar as it reduces micro‑friction and helps sustain continuity of attention at exactly the moment where thinking is fragile.. Everything else (split/merge/OS settings) is only in service of that goal.

4) Where I fully agree with your “missing piece” hypothesis

Your “bottom line” resonates strongly: if Tinderbox offered a smooth method to open a different target note as a stand‑alone window via an incremental search or prompt (akin to the zip‑link path matcher), then much of the window choreography would indeed become unnecessary.

And this is precisely what I mean by Tinderbox as a tool for thinking: not “more UI,” but a shorter path from intent to action, so the thought is not lost while managing context. If there is an established technique today (even if it is slightly indirect) that approximates this — for example via Quick Find, a specific view, or a repeatable pattern you have seen work — I would very much welcome that guidance.

5) A small but important clarification of my stance

I am not arguing that there is one best workflow for everyone. Screen size, number of displays, and individual working style clearly matter — as you noted. My claim is narrower:

  • There exists a “thinking‑flow” mode of work in Tinderbox where micro‑friction matters disproportionately.
  • The window/tab/merge behaviour is relevant only insofar as it helps enter that mode and remain there.
  • Therefore, my interest is: what practices, affordances, and UI paths best protect that mode, across different setups.
3 Likes

If I follow you, one situation where this might be invaluable would be a set of notes to which you may need reference at any time, but that aren’t necessarily linked to the context of the note you’re reading. For example:
• lists of papers you intend to consult
• Luhmann’s index of entry points
• glossary of key terms, acronyms, and unfamiliar vocabulary
• lists of experiments you plan to run
• lists of potential venues for papers or presentations
• directory of TODOs in a large refactoring, or PEOPLE you want to contact during a conference
So, in a secondary window off to the side, you can have any or all of these available in easy-to-see tabs.

@andreas Thanks, that’s useful clarification of the underlying drive and I think @eastgate has also postulated a useful set of contexts for where this sort of quick access to other windows—rather than have them all open all the time—might help in the future.

With your notes above and (soon) an article in aTbRef referring to how to turn on OS-level app-window grouping, I think we should have some guidance for what is possible today.

1 Like

Yes, exactly, Mark!

And the list could be continued indefinitely and further expanded to such notes which are brought from DevonThink into Tinderbox to be visualized there, more quickly accessible, serving as a more prominent trigger point to quickly return to DevonThink from there.

Or – and this being a feature request :folded_hands: – posters could also be made prominent in this way. For the time being, however, poster cannot be displayed this way (see the GIFbelow).

As I said, the list is endless, but the underlying principle is wonderfully exemplified by your example-list. Thank you for that.

poster no preview yet

2 Likes

Once again, @mwra, what would we do without aTbRef. Thank you ever so much!

1 Like