On Window Managers and the UNIX Philosophy
------------------------------------------
Sun Nov 27 22:32:09 EST 2022
Ok, so the title is a bit clickbaity, but I needed something
more specific than "On Window Managers".
Really what I hope to explore in this entry is:
> Why don't more applications leverage the window manager?
## Backstory
In my internet research on CHICKEN Scheme, I stumbled
across Felix's website (the original author) [1]. He has
some projects listed, including a Acme-like editor he
develops. As an Acme enthusiast myself, I had to check
it out!
The editor is called ma [2] and I'm using it to write
this post. It has the classic look and the mouse
chording/plumbing (and to my pleasant surprise some emacs
and CUA hybrid so Ctrl-S/C/V saves/copies/pastes and
Ctrl-N/P go up/down, etc).
The most interesting thing about ma(1), however, is that
it only supports a single buffer per window. To handle
multiple files, run multiple ma(1) instances. They
communicate with a registry, if needed (presumably for
things like "does anyone have this file open already?").
From the README:
> ma ... needs a tiling window manager to be used in a
> satisfactory way.
This is such an interesting concept, I had to write about it.
[1]:
http://call-with-current-continuation.org
[2]:
http://call-with-current-continuation.org/ma/ma.html
## On Leveraging the Window Manager
The more I looked around, the more I realized... most
applications have their own window manager. Splits in
Vim, tabs in Firefox, heck Emacs even _calls_ their splits
"windows" (vs "frames" for X11 windows). Terminals
frequently have tabs/splits, and for those that don't
tmux(1) can be used!
To these apps, the window manager is a foe, not a friend.
It will resize them, force them to adapt. They really
don't seem to be built to work in tandem.
On the other hand, these apps aren't really doing anything
tiling window managers can't. Tabs, splits, stacks... I'd
argue tiling window managers provide more flexibility
than any home baked solution.
Further, each app has a slightly different set of key
bindings to use their window management. They _have_ to
be different because frequently users nest apps within
apps (think vim in tmux in gnome-terminal ctrl-t for gnome
tabs, ctrl-a[num] for tmux, :tab for vim).
Wouldn't it just be cleaner to pull a ma(1) and leverage
the window manager? This would mean:
1. Uniform key bindings between many app types
2. The ability to stack/tab/split between different apps
(2) can't be understated--it's so cool having ma(1) split
in the main panel, firefox and st(1) on the right. If I was
in vim, I could have my shell and editor, but surely not
the browser in the same "grid"!
Off the top of my head there's only two reasons _not_
to do this:
1. (lesser) Needing to run a "registry" to synchonize
multiple apps is kindof awkward
2. (more importantly) The majority of computer
users just don't (and can't) use a tiling (or otherwise
configurable) window manager.
With Windows and macOS having the majority of users, of
_course_ firefox needs to have its own tabs (and so on).
There's simply no sane way to manage your 30+ tab session
as floating windows.
## Wrapping Up
It seems, unless there's a massive shift in how mainstream
desktop window managers work, that writing ma-like programs
that rely on a window manager for basic things like
multiple files is a pipe-dream (unless you drastically
shrink your audience size). That said, it's an interesting
way of dividing the responsibilities; if you can do one
thing only, and do it well, surely you should focus on
being an editor and not a window manager :)
