Comment by Twey
1 day ago
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…)
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.
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.
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.
Im not sure gimp being constrained to a single window would constitute a multi-document interface.
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.
1 reply →
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.
1 reply →
> 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.
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.
3 replies →
What about Cocoa?
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.
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?
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!
One could argue that this affordance should be provided by the OS for a unified experience.
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.
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.
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)
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).
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.
3 replies →
I just logically group tabs into the same terminal window. All OS's have hotkeys for switching between tabs and windows.
1 reply →
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.)
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.
1 reply →
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.
2 replies →
I would typically not bother with tmux unless ssh is involved.
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.
>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.