Infinitely Nested Window Management | Hacker News Reader

Infinitely Nested Window Management

amadeuspagel.com

36 pointsamadeuspagel38 comments

Don't know about the need of INFINITE nesting, but damn is that frustrating when apps copy browsers-style tabs but don't provide the ability to rip one tab into a completely new window.

I'm not blaming apps creators, cause (AFAIK) this whole "tab into window" transformation is completely custom made by browsers and also at least somewhat hacky.

Would be nice for microsoft to notice and make a 'tab' a native component, and automatically handle transformation. Especially since their own, non-browsers apps like explorer, terminal or even notepad started to implement tabs. But without that ability to rip it out, it really feels unfinished.

If it was native, we could even stack tabs from 2 different apps next to each other, as if they were websites! ...full circle back to task-bar :[

> If it was native, we could even stack tabs from 2 different apps next to each other, as if they were websites!

Haiku can do that:) I think I've seen it in X11 window managers as well but I don't recall...

i3 can do that.

So can XMonad, to some extent, though it’s not in the default configuration.

There is some previous art in mainstream OS’s about this, and it was all as great as you put it tbh

macOS made the tabbing native by giving windows (only of the same app) the ability to get merged into a single window with a tab bar (in Sierra https://www.macworld.com/article/228274/how-to-use-tabs-in-m...). It all has the same behaviors as Safari, including the one of “popping out” a tab into its own window. Apps that use the native window controls and the native window lifecycle manager get it for free and by default, but there is no way to get it otherwise (AFAIK), and apps can opt-out.

Windows 10 had this feature for a while in the Insiders build, called “Sets” (https://arstechnica.com/gadgets/2017/11/tabs-come-to-every-w...), which made every window available to be tabbed together with any other window, from any app, no specific code or framework necessary. It worked very well and was neat af, but it got scrapped :( https://www.windowscentral.com/microsoft-shelves-windows-10-...

There is a reimplementation of this by Stardock https://www.stardock.com/products/groupy/

On a personal note, I’ve been using Arc’s implementation of Spaces and Tabs, and it feels super natural and productive. With some tweaking, I think this would be a great UX for window managers, and I’ve found myself really needing it for my whole OS. Maybe Stage Manager can get there at some point (although right now it is bad as hell).

> this whole "tab into window" transformation is completely custom made by browsers and also at least somewhat hacky. Would be nice for microsoft to notice and make a 'tab' a native component, and automatically handle transformation

As it is, it never seems to work quite right and is easy to activate accidentally. Dragging a tab slightly downwards in firefox, but not out of the window at all, only out of the tabbar region, will result in that tab being turned into a new window. I would expect new windows to be created only if you drag the tab outside of the current window, but that's not how firefox does it.

This is easy to do accidentally if you are being sloppy with your mousing, and particularly, if you're using a touchpad with libinput which sets "Tapping Drag Enabled" to 1 by default. Tap the tab button, put your finger back down on the touchpad and move the cursor... ooops you just dragged the thing you clicked!

I remember FVWM was able to put windows inside its panels so it was possible to make a tabbed window that contained different programs. It is very customizable and fun to play with when you have the time.

I've been fiddling with my environment the last few days. Looking at replacing nvim with helix, zsh with fish, ubuntu with debian, etc.

I agree to some extent, that there should be more structure or integration to workspaces.

tabs should be a part of the windowing system, for example, not something apps do themselves (and all differently). Then, the windowing system could support breaking out tabs to new windows, navigating between them, etc, in a manner consistent with the rest of the window system. The same with terminal multiplexers, etc. With text editors, some text actions could be defined universally, and mapped to keystrokes, so that in any editing environment, you have a consistent set of affordances. Why is the editor managing 'splits', when the terminal multiplexer, if not the window manager, should be doing this? You end up having to define (often conflicting) key mappings in multiple apps to get any kind of overall-usable/consistent setup.

Etc. I agree the current situation is a mess.

You can get a long way with neovim. I use it as my text editor, ide, and terminal multiplexer. Consistent tabs, panes, text editing, etc. If it supported a terminal graphics protocol it would be just about perfect.

Yes while you're in one 'garden' everything is rosy.

How do you switch to other apps, or between virtual worksapces though? All that's defined by the terminal emulator, or window system, outside of nvim, and hopefully it's consistent or at least doesn't conflict.

So I guess the OP argument is that everything should be in the 'window manager' garden, instead of all the apps making their own little alcoves with their own custom little languages.

The traditional emacs solution is to move everything into emacs, and they actually follow through (emacs can, in fact, be a window manager, web browser, and terminal emulator).

That's how I use emacs every day. Once it is open, I rarely need to do anything outside of it. Code, compile, debug, web search, etc. It can handle everything I have thrown at it.

lol, emacs can do everything. Shame my wrists aren't compatible with it's keyboard command architecture.

Have you tried using a prefix-based window manager? Now I have the same keys in window manager, multiplexer, and editor, just with different prefixes. It also nests well if you do remote or virtualized graphical sessions.

I wonder if anyone already made tabs for StumpWM..

On macOS the concept of tab is a part of the window management system. However a lot of apps decide to do it themselves anyway—and given the stage of the window manager of macOS I can’t really blame them.

>If the idea of a filesystem limiting the depths of nesting sounds insane, imagine a filesystem where every level of nesting is conceptually different, where there's one program that you use to manage some levels of nesting and another program for other levels of nesting, where you can't move things from one level to another.

>That is the state of window management today

Why is this insane? Unlike directories in a file system, different levels of windows are conceptually different; it would make no sense to be able to embed a workspace (top level) into an alert box (lowest level), or a browser tab (middle level) in a terminal (unrelated middle level).

That the author has no justification for why they think this is “insane” nor any suggestions for what should be done differently speaks volumes.

There are many reasons I might want to combine browser tabs and terminals.

For example, I might have a web server running in a terminal and the website open in a browser tab. Wouldn't it make sense to have the terminal in a tab, next to the browser tab?

Or I might see some error message in the terminal and google it in a browser tab.

>Wouldn't it make sense to have the terminal in a tab, next to the browser tab?

Yes, the operative word is next to. This is already possible with any of today’s window managers (just drag the windows next to each other). In fact, certain tiling window managers (e.g. i3, notion) make it possible to permanently place the terminal as a tab next to the browser window, and move the two around as a unit.

You still haven’t made a case for arbitrarily nesting windows, which was the feature desired in your original post.

What I would like to have is the desktop split into separate areas (windows?) and that not be restricted (not only half or one quarter, but arbitrary many splits). Then, any split could have a number of tabs, including just one. And the tabs could be anything. The right half of my screen could be a container with tabs, and one tab be a terminal, one be a browser, and one be a text editor.

Currently, the text editor can have tabs, but they are all text files, the terminal can have abs, but they must all be terminals, the browser must all have tabs with pages...

The whole desktop being managed like an IDE seems like it would accomplish it.

On a separate note, there seems to be something wrong with the analogy you're using. You say it does not make sense to have a terminal in an alert box. Going with the filelsystem analogy the author suggested, that would be like having a directory inside a text file. Yeah, it doesn't make any kind of sense. There are intermediate nodes (folders, windows, tabs) and leaves (files, editors, web pages, videos, terminals). The point seems to be to have infinitely nested intermediate nodes, and leaves at any level. So the alert box could be inside 5 window splits and 3 tabs, but of course inside it would never be anything else.

Tiling window managers like i3 do everything you described.

I mostly use windows, and that's my problem, of course.

But with i3/xmonad, if I run vscode or intellij, can I have the file explorer view be in a different place in the hierarchy than right next to the source editors?

IntelliJ lets you split out its internal file explorer view into a separate window, so you can place it anywhere in the hierarchy, even in a separate virtual desktop.

vscode doesn't let you split out the internal file explorer view, but the reverse is possible- you can quickly open any file in its own window, which can then be placed arbitrarily.

Many tiling window managers also allow you to group arbitrary windows into tabs.

much of what you're suggesting can be done with a tiling WM. In Xmonad, I do something similar with a concept they label "workspaces", in that a given workspace has an accreting collection of features which can be summoned and set aside as a unit. The intermediate unit is a tile, and tiles can be hierarchically composed.

You're making the case for arbitrarily nesting windows for me. When you talk about placing the terminal as a tab next to the browser window and being able to move the two around as a unit, you're talking about creating a new window that contains both the terminal and the browser window.

>Wouldn't it make sense to have the terminal in a tab, next to the browser tab?

ChromeOS does this with crosh.

Author doesn't say that there should be know limits for certain hierarchies if they make no sense like a workspace in an alert box.

But what about a workspace in a workspace in a workspace etc.

One is a limit based on the logic of a hierarch, the other ist jus a limit.

The former is a strict rule, no workspace in an alert box, the latter depends on the level inside the hierarchy, one is obvious, one might be hard to know and keep track of.

> or a browser tab (middle level) in a terminal (unrelated middle level).

That sounds a lot like jupyter

my analogy would be that you have a house, in that house you have rooms and in those rooms you have humans

why you cannot have houses inside humans?

while analogy to a filesystem would be: you have a box, and in that box you can have another box, and another etc.

Exactly, nobody (sane) would complain that you can't put a folder in a file but why is there only a certain level of folder depth allowed?

AFAIK there is no limit of depth in modern filesystems (at least in design), there is usually limit in path length (in bytes) but that's just that you have to limit somehow implementation to prevent pathological instances.

Eg imagine bug in some script that create some directory structure in a loop and bug that causes it to create infinite depth.

It makes sense to say "enough" at some point, otherwise you could destabilise whole system.

macOS’s new Stage Manager feature does this.

For an example of a system that does indeed do this, see Plan 9 where the window manager can itself run inside a window. Why might you want to do this? Well, you might be connected to a remote machine in that window (akin to SSH) and want to see your desktop there.

https://youtu.be/TFhQi0xbrOk

Yes it's a mess, as confirmed by operating system vendors' constant struggle to fix it: Windows, tabs, views, widgets and mini-windows, along with Exposé, virtual desktops and now Stage Manager are all symptoms of the same issue: dealing with unlimited hierachies with limited screen real-estate.

An unlimited screen wouldn't really solve much. The real limitation is our working memory – a cognitive problem. Visuals are there to offload working memory, and when you find yourself having three different windows of the same folder, you know visuals has failed at its job.

Surely Stage Manager might give us an extra "cognitive percent". Improved visuals, cues, an extra metaphor here and there might give us another percent. But at the end of the day, I think we reached the end of the road unless we rethink the concept of files, folders and the "jurisdiction" of applications. So at some point down the file hierarchy, arbitrary applications take over and visualise the rest of the hierachy in whatever unorthodox, material style of the season. However a browser window is a container and its tabs are locations, i.e. files in some aspect. A bookmark is also a file. The Photoshop pane of Patterns is also files inside a container. And since the hierachy is hijacked by applications, browsers must afford their own ways of sharing content besides the operating systems sharing mechanism.

To add to the mess we have Open and Save dialogs, which is just another unneccessary way to visualise the same file hierarchy, with their own means of navigating and creating new folders.

My $0.05: Let applications visualise and edit files, and leave the handling of hierachies to the next generation of operating systems. That way the nice patterns in Photoshop could display as a pane in the operating system hierachy since the operating system leaves the rendering to Photoshop (if it's available). Tabs doesn't have to be tabs. They could be displayed as vertical lists or thumbnails, however the content of each tab thumbnail would be rendered by the browser. A container of tabs (really "bookmarks with a state") could easily be moved to another application or browser.

I really wish Apple had taken initiative with OSX and made tabs something that could also be exploded out through Exposé, alt-*, trackpad gestures, and other shortcuts.

They had it within grasp as they rewrote the UI APIs, they just didn’t choose to go that far.

Chrome android handles it really well. You can set a flag that turns all chrome tabs into individual activities.

Obligatory Plan 9/rio mention.

i3 kinda does this. It manages workspaces/windows/tabs. I use qutebrowser and it has the option of 'tabs as windows' so that i3 can handle my browser tabs. My user experience is pretty consistant across my entire system.

Firefox doesn't allow each tab to be a window, which breaks the consistancy but i only sometimes have to use that.

But as has been mentioned, plan9 does this at a design level.

Reply on news.ycombinator.com