1. 29

  2. 12

    Can we please stop using tabs altogether (the last vestigial remain of MDI) and move towards BeOS’s Stack paradigm in which each window title is “a tab” and you can stack together different windows?

    The stack paradigm is easier for the users: one concept (windows) instead of two similar-but-different concepts (windows and tab-inside-windows).

    A graphical example: https://www.haiku-os.org/docs/userguide/en/images/gui-images/gui-s+t.gif

    1. 7

      Every time I see tabs mentioned, I’m thinking about window management. The window manager is too weak, and therefore the application themselves had to step in and invent their own.

      So basically agreeing :)

      1. 5

        Counterpoint: there are two major kinds of tabs, which the article seems to think about as dynamic and static. I would call them task-windows and multi-rooted trees.

        A task-window is the kind of tab that MDI and browsers use: effectively a complete copy of the application main window, but space-compressed. A perfect window manager might be the best way to handle these, but it would have to be good enough for every application’s needs. I haven’t met a perfect window manager yet, but I haven’t seen them all.

        A multi-rooted tree is most often found in giant config/preference systems, e.g VLC and LibreOffice. It could be represented as a single-rooted tree, but the first level branches are trunk-sized and so independent that a user will often only want to tweak things in one branch. Separating them out into tabs is a pretty reasonable abstraction. It’s not the only way of breaking the tree up, but it maps nicely from category to tab, subcategory to delineated section.

        1. 3

          Another counterpoint is Firefox with a lot of tabs. There are some optimizations that Firefox can do because it has access to domain knowledge. Like not loading all of the tabs on start. It could probably unload tabs as well. In order to do that the window manager needs to expose a richer interface.

      2. 4

        Former BeOS fan here.

        Please no. :-(

        This is all IMHO, but…

        There are at least 2 different & separate usage cases here.

        № 1, I am in some kind of editor or creation app & I want multiple documents open so I can, say, cut-and-paste between them. If so, I probably mainly want source & destination, or main workpiece & overflow. Here, title-bar tabs work.

        № 2, I’m in a web browser, where my normal usage pattern goes: home page → lots of tabs (50+) → back down to a few → back to lots of tabs (and repeat)

        In this instance, tabs at the top no longer work. They shrink to invisibility or unreadability. In this use case, I want them on the side, where I can read lots of lines of text in a column of a fixed width. Hierarchical (as in Tree-Style Tabs) is clever, yes, but I don’t need I already have a hierarchy: a browser window, and inside that, tabs. Those 2 levels are enough; I rarely need more than 2 or 3 browser windows, so I don’t need lots of levels of hierarchy in the tabs and TST is unnecessary overload and conceptual bloat.

        The fact that Chrome can’t do this is why I still use Firefox. Or on machines where I don’t have to fight with Github, Waterfox, which is a fork in which XUL addons still work & I don’t need to lose another line of vertical space to the tab bar. In Waterfox as in pre-Quantum Firefox, I can combine my tabs sidebar with my bookmarks sidebar, and preserve most of those precious vertical pixels.

        We have widescreens now. We have nothing but widescreens now. Vertical space is expensive, horizontal space is cheap. Let’s have window title bars wherever we want. How about on the side, like wm2? https://upload.wikimedia.org/wikipedia/commons/3/3b/Wm2.png

        That worked well. That can mix-and-match with BeOS-style tabs very neatly.

        1. 4

          Microsoft was working on a feature called Sets for Windows 10 that would basically do this. I was very sad to learn that the project was axed though even after making it into an Insiders build :(

          1. 2

            Compare with tabbed application windows in current macOS. In almost any Cocoa app, tabs can be torn off to make their own window, or merged with another window. I’m not as familiar with Be, but the main differences seem to be that tabs still go in a bar under the title and can only be joined when they’re the same kind. I’m curious how stacking windows of different kinds would feel. Maybe a window would become more like a task workspace.

            1. 2

              I like the idea, and have tried it in Haiku, but in practice it was harder to use for me.

              Maybe I missed some shortcuts? I was dragging windows to each other manually.

              Maybe it’s just a matter of getting used to it? I don’t know.

              1. 3

                Applications, like web browsers, could create shortcuts for creating a new window as a tab of the current window. I think that would make it near identical in terms of behavior.

            2. 2

              Looking forward to this and many other things in Gnome 40. :)