Hacker News Reader

Comment by Twey | Hacker News Reader

I've always thought ‘multi-document interfaces’ as we used to call them are an anti-pattern. I have a perfectly good window manager; why does every app need its own incompatible, usually inferior window manager built in?

(Mind you on mobile I very much don't have a perfectly good window manager, and indeed can't even open multiple instances of most apps…)

View on HN

As a long time Mac user, MDI has always felt like a stopgap to make up for the OS not having the ability to manage windows on a per-application basis (so for example, being able to hide all windows belonging to a particular application or move them all to another desktop/screen).

It also feels very foreign on macOS - Photoshop suddenly gained the MDI-type UI in like CS4 or something, after having let windows and palettes roam free on macs since Photoshop’s inception. I always turn it off, feels claustrophobic somehow.

I think that's still a little too restrictive. Sometimes you really do want multiple groups of windows that may belong to the same (think multiple browser windows each with multiple tabs) or different applications (e.g. grouped by task). It's not hard to see how the application marketplace leads to every app doing everything including managing all the things it does, but it's not good for the user.

Custom groupings is a nice feature too, but that feature can live happily alongside app groups. In fact I think the two would compliment each other nicely.

Well it subsumes app groups, I think? If anything app groups become just a default/prebuilt grouping policy.

Compared to the experience of something like “Gimp”, I prefer something contained to a single window.

Otherwise two or three such apps running at the same time becomes a game of “where’s my window”. I hate the idea of a toolbar being its own window to be managed.

As a long time Gimp user, I remember dealing with the same thing but they did eventually fix that. It actually runs in a single window by default now.

I mean, old photoshop versions (CS3?) also used multiple windows, so if I were to take a guess that’s where Gimp got it from.

"palette" windows were common in a lot of creative applications for a really long time. it seems like with larger screens and higher resolutions, that's a lot less common by default than it used to be.

They indeed feel way less of a pain than dealing with an app with complicated UI stuffed into a single window on a screen with half the size the app was designed for. Even with the site we're discussing here, once I cranked scaling to 200% it became noticeable harder to read than a regular webpage with some text on it would with the same scaling.

However, I believe there is a better way to approach this: put each significant piece of functionality into a separate window or even executable, and use regular moveable toolbars and well-known hotkeys inside each window. One window for code editor (with working Ctrl+Tab and Window -> Tile Horizontally menu), another for configuration, yet another for terminal and output window (with a Pin on top button). When I write code I don't normally need configuration tool, but if I need it even so often it gets opened alongside the editor and is now one Alt+Tab away, not taking any screen space at all.

I used an engineering tool suite written with this approach and it was much better experience than the single-window monstrosity that came as a replacement, stuffing entirety of functionality into a single app and breaking (not implementing) a lot of small conveniences like aforementioned Ctrl+Tab.

That is because you are used to shitty window managers / desktop that don't remember position, do not support pinning and tagging windows, etc.

That is the issue, apps have to deal with the lowest common denominator in term of desktop management but there is absolutely no good reason to build a window manager inside a website.I think that with tabs people have generally forgotten they can open multiple browser windows.

Im not sure gimp being constrained to a single window would constitute a multi-document interface.

> I have a perfectly good window manager; why does every app need its own incompatible, usually inferior window manager built in?

Because some applications do need multiple windows in the same application context. A common example would be image editors.

It is unfortunate that almost all generic MDI implementations (Win32 and Qt basically) are incredibly barebones. I want to have multiple windows visible when i'm using Krita, for example, but Qt's MDI support (that Krita does use) is worse than what Windows 95 had.

What about Cocoa?

The ‘application context’ isn't a concept that adds value, at least for the applications I've seen. For things where the application windows do need to be treated differently (e.g. patch bays that can be connected together, or widgets that can be fused into larger widgets [1]) I have more sympathy for applications that want to do their own window management. But for something like the browser just grouping Web pages together, that's something entirely unrelated to the browser functionality that should be available in the window manager.

[1]: https://wiki.haskell.org/Eros

Well, yeah, it doesn't fit all applications and web browsers are a case where MDI doesn't really work. The linked site is more of a gimmick, at least as far as the documents go.

But my response was about calling MDI an anti-pattern in general. Just because it doesn't fit all cases, it doesn't mean it is an anti-pattern.

Oh no I get that the in-site MDI is a funny stylistic choice, and I've no problem with it. But the thing it's poking fun at is in-browser MDI, hence the comment.

I stand by the anti-pattern comment. I think there are very, very few cases where ‘MDI’ is appropriate, and I put it in quotes because the things being managed in that case are almost never ‘documents’ in any meaningful sense (rather they're some kind of graph node). Functionality apps build with MDI is basically always independent of the actual app and would be better implemented in the window manager — and more often than not there's actually no additional functionality over even the lowest common denominator of window managers.

Well, i already mentioned an example: image editors. IMO image editing is one of the perfect cases for MDI because not only you can have multiple images visible at the same time, but also multiple views of the same image (useful for pixel art, for example). Most MDI applications allow you to dock and/or float stuff in the edges/over the windows which is useful to avoid repeating the same chrome at every window (which is what a lot of applications that support multiple documents with toplevel windows do).

In theory you can have multiple toplevel windows with separate windows for the control stuff (tool window, tool options, panels, etc like GIMP has) but in that case you really need a virtual desktop dedicated to the application itself. Personally i prefer to dedicate virtual desktops to tasks (i have a fixed number of virtual desktops and their shortcut keys have become muscle memory over the years), so e.g. anything graphical goes into the same virtual desktop, but -say- GIMP in multiwindow mode feels awkward to use alongside Blender. Krita having an MDI mode is much better IMO, even if Qt's MDI support is primitive at best.

There's nothing stopping a window manager from supporting docking windows to each other, or the more common option in tiling window managers of having nested tiling groups so you can arrange your editor windows however you like and manipulate them together. Metisse [1] takes it even further, letting you slice a ‘palette’ out of one window and put it in another. In practice I, like you and I suspect a lot of other people, use workspaces in lieu of task groups, which works fine for simple use cases and small monitors.

The only applications that really need MDI are those that do something with their windows other than window management, which (loosely) implies that those things are something other than windows.

[1]: https://en.m.wikipedia.org/wiki/Metisse

There is a lot of stuff that window managers could in theory do (e.g. something i'd like Window Maker to be able to do is "combining" windows so that the title bar becomes a tab bar that contains multiple windows in the same screen space region) but in practice never end up doing for whatever reasons (i could in theory spend the time to implement such a feature in Window Maker but it is very low in my priorities for whenever i have time to spend). And more importantly, not everyone has the same window manager, so even if my window manager could provide a feature that made some application feature unnecessary, someone else's window manager might still not provide it (but might provide some other feature they want that mine doesn't).

> The only applications that really need MDI are those that do something with their windows other than window management, which (loosely) implies that those things are something other than windows.

Well, in the example of image editors i mentioned, these windows are views to the underlying image documents - and being able to move and resize those views arbitrarily, together with a caption about the document they're about, is very useful. It also matches perfectly with embedded/MDI windows.

Sure, I buy that window managers are, on the whole, not capable of the things that people want them to be capable of. My gripe is more that, instead of improving existing window managers to do those things or building a new one with the features people clearly need, developers choose to build their own special-purpose window manager with the features their app benefits from the most and then embed it into their app so those features can't be used with other apps. It reflects, IMHO, a culture of siloing technological developments to the (financial) benefit of their developers and the detriment of users.

XMonad supports tabbed groups, by the way, as (apparently) do i3wm, Sway, and Hyprland.

> Well, in the example of image editors i mentioned, these windows are views to the underlying image documents - and being able to move and resize those views arbitrarily, together with a caption about the document they're about, is very useful.

Sure, it is. That is also exactly the set of features of a window manager :)

To throw gasoline on the fire: this how I’ve always felt about tmux. Why use an incomplete in terminal windowing system when I can just have multiple terminal windows open managed by the superior OS window system.

(That said I know tmux is sometimes the only option and then it makes sense to me)

tmux (and screen) are incredible assets for remote sessions, both for continuity across dropped shells and multi-shell activities when the connection process is tedious (multiple jumphosts, proxies, etc.)

The continuity benefit is much less than it used to be, now that we have systemd with `enable-linger` so we can make proper daemons.

that's not what tmux provides continuity for. the continuity is for interactive sessions. on my server i have more than 20 tmux windows, each one for one specific purpose. they have been running for several years.

My point is that a lot of hysterical-raisin interactive sessions really don't need to be.

I've fallen out of using it, but for a while I was using dtach to do similar without the virtual terminal multiplexing. Much much more direct.

I'd just run a vim session. If I needed terminals, they were in my vim! Even wrote a short shell-script to automate creating or re-attaching to a project specific vim session. https://github.com/jauntywunderkind/dtachment

Haven't looked into it, but I'm love a deeper nvim + atuin (shell history) integration.

It might be quite similar window/tab managing functionality, but for me it's the same thing that made me choose tmux over screen: it comes with a nice status bar as default and hotkeys are somehow easier to memorize.

My dtach+nvim uses nvim as terminal multiplexer & "status bar", which is pretty ok! Dtach only serves as a very very dumb pass through (where-as tmux really is a persistent virtual terminal that clients can read-out from).

because the OS window manager isn't superior. i have two dozen tmux windows in half a dozen sessions locally. i have shortcut keys to switch between sessions and between windows. i can do that while mixing the terminal with other gui apps. i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.

> i have two dozen tmux windows in half a dozen sessions locally.

> i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.

Locally-speaking, I don't really see the point of mixing tmux sessions and tmux windows. I wonder if you mean "sessions" -> tmux windows and "windows" -> tmux panes.

What about i3/sway? You can have a tabbed container (functions like tmux windows) with split containers inside (functions like tmux panes). You can even float the tabbed container with all windows organized inside.

I don't really see the point of mixing tmux sessions and tmux windows.

sessions let you group windows. i have a group/session for each project/purpose. one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work.

sessions also means that i can connect to tmux from multiple terminal windows. i generally have two windows, one for dev work and one for everything else.

generally i feel that having more than half a dozen windows in a session makes the session unwieldy, harder to navigate, because it becomes more difficult to find the window i am looking for.

which would be the same problem if each was a gui window. try to find your way around 20 gui windows.

> one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work.

Why would you have all those open at the same time, though? Isn't that incredibly distracting? (Disclaimer: I have no experience with tmux to speak of, beyond briefly trying it once or twice.)

not being distracted is the whole point. if i have everything in a window, then i would have 20 windows. that would be distracting. with tmux i only have one visible window and all other windows are hidden, and i switch to the window i want to use. (ok, i could do that with gui windows too, i am just making a point)

these things are open because otherwise i would have to open them and close them every time i want to use them. by keeping them open i can switch back and forth faster. but, while i am not using them they are invisible. and i don't notice that they are there.

> generally i feel that having more than half a dozen windows in a session makes the session unwieldy

> which would be the same problem if each was a gui window. try to find your way around 20 gui windows.

I mean, just like how you can organize tmux windows in tmux sessions, you can organize gui windows in workspaces and containers to arbitrary depths.

you can organize gui windows in workspaces and containers to arbitrary depths

which GUI offers that? i have only ever seen a single level: workspaces and windows and tabs. that's not enough.

by using tmux i get those three GUI levels and the three levels of tmux

> which GUI offers that?

The ones I mentioned: i3/sway. There's probably other tiling WMs that similarly allow organizing windows into trees of containers of arbitrary depths. The containers being able to be set into 4 different modes for displaying the containers/windows within: split horizontal, split vertical, tabbed, or stacked.

very well, thanks. i'll give that a closer look.

I just logically group tabs into the same terminal window. All OS's have hotkeys for switching between tabs and windows.

sure that works, but then you are also using terminal functionality and not the window manager, which still shows the window manager as lacking in features, which was the argument i was responding to.

seriously, a window manager that can group windows and manage those groups would be awesome. workspaces help, but they are often just there, and can't be managed, reordered, named, etc..

actually, i think kde may have some of that functionality.

i still prefer tmux in any case because it is more scriptable, and it provides a detach function. although i recently started exploring wezterm, which can be configured to work like tmux and also has a way to detach and reattach sessions: https://news.ycombinator.com/item?id=44762241

I would typically not bother with tmux unless ssh is involved.

I tend to run my tmux session for months at a time on my office workstation. When I remote in to that computer, I can type ‘tmux attach’ and all my context is there. I might have four long arc dev projects running at once, and my planning system, all within those windows.

On our datacentre servers, I also have tmux running. It is fast to connect to these hosts, attach tmux and continue from where I left off.

Another use case: it is common for corporates to require devs to use windows desktops, but to then give them a headless linux host in a datacentre for development work. Here, you use putty to connect to the linux host, fullscreen it, run tmux. On your desktop you have outlook and office and putty and a browser and no dev tools. You can do all your planning and dev work on the linux host, using your favourite ten thousand hours text editor and building your own tools, and this becomes your hub. You lose awareness that you are connected to this from a locked down windows host. Corporate security reboots your windows host for patching several nights in a row, and it does not cause you any hassle because your work context is in the tmux session on another host.

The difference is that tmux, with all its state, typically runs on a remote system. The graphical equivalent would be a VNC &c. session, assuming that the remote machine has the prerequisites for that (which is a pretty big ask).

I think the issue is partly that most OS window managers really don't seem to optimize for having a dozen small windows on your screen in the way that the custom window managers in, say, art software or CAD software, often do. Mainly in terms of how much space their title bar takes/wastes.

>why does every app need its own incompatible, usually inferior window manager built in?

You answered your own question, because a lot of applications work across multiple platforms, and if you want to have control over the experience because you don't know what capacities the OS's window manager has you need to abstract it away.

Abstracting something away and duplicating it for yourself are two very different things! Remember Java Swing?

But I take your point, if you want to target the lowest common denominator of window managers it makes some sense to do your own window management. Mind you you could just ship both a browser and a window manager…

I wonder to what extent the pattern of applications doing their own window management masks (and therefore perpetuates) the problem of inadequate window managers.

Nearly every UNIX command has its own way of formatting output, be it into columns, tables, lists, files, or TTYs (and windows, à la emacs, screen, other curses-based utils...). Even `ls` has a table formatting logic to it. This keeps the UNIX native abstraction relatively simple; everything is "just text." But the ecosystem, being quite rich, actually has a lot of divergent requirements for each utility. If that was avoidable, we probably would have seen some other abstractions appear on top of "just text," but we similarly haven't.

Would you extend that argument to tabbed interfaces as well? Why should browsers support tabs (and an inconsistent interface by each vendor), when you can just open a new window instead?

One could argue that this affordance should be provided by the OS for a unified experience.

The tabs reuse resources of the browser, and the browser does it really well - I think it's not even arguable that browsers are more complex than the OS GUI API, this is why e.g. Windows 11 uses react.js in start menu.

So if you create a webpage that is so damn advanced that it beats the browsers OR it somehow reuses heavy resources within one webpage, I'd say this is a good justification. And IMO the OP link isn't an example of that.

> Windows 11 uses react.js in start menu

They do what?!

EDIT: Sounds like they only use it for the "Recommended" section, though? https://news.ycombinator.com/item?id=44124688

Even better, WMs can (and sometimes do) support tabs!

Because browsers only remember the last set of open windows reliably.

So if I were to split the 5 tabs I usually need for work in 3 windows I would routinely lose a bunch of them.

I thought that on MS Windows MDI is part of the operating system. There are programs that can change it at runtime. That's honestly pretty neat.

Reply on news.ycombinator.com