d0f7acf9eb
An x86-64 operating system built from xv6, now largely rewritten: SMP, a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF rasteriser, and a Linux-numbered syscall ABI. No history before this point -- the tree was never under version control. This commit exists so the rename that follows has something to undo to.
27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
# SchWM — the Schunix Window Manager
|
|
|
|
Policy. Where windows go, which one has focus, what happens when you drag a
|
|
title bar, how alt-tab behaves, what a window looks like at its edges.
|
|
|
|
SchWM is a *client* of Schcom, not part of it. It talks the same protocol
|
|
every other client does, plus a privileged extension that lets it position
|
|
and stack surfaces it does not own. That extension is the entire difference
|
|
between a window manager and an ordinary application.
|
|
|
|
## Status
|
|
|
|
Not started. Blocked on Schcom, which is blocked on the kernel — see
|
|
`../schcom/README.md`.
|
|
|
|
## Why it is separate from the compositor
|
|
|
|
Merging them is the common shortcut and it is the one that hurts later.
|
|
Compositing is mechanical and must never stall: it runs every frame and a
|
|
mistake there is a frozen screen. Window management is policy, full of
|
|
special cases and personal taste, and it changes constantly. Putting them in
|
|
one process means every experiment with focus behaviour risks the thing that
|
|
puts pixels on the screen.
|
|
|
|
Keeping them apart also means SchWM can be restarted, replaced, or simply not
|
|
run. A Schcom with no window manager should still show a full-screen client —
|
|
that is a useful state to be able to reach when something is wrong.
|