57aff40228
docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.
A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.
So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.
schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.
Three corrections found on the way, all load-bearing:
* projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
* The root README said "No TCP/IP" months after the stack landed.
* history/kernel.md sec.7 was marked "in progress" on a problem that process
groups solved.
Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
1.5 KiB
SchWM — the SchOS Window Manager
Superseded. In Wayland the compositor is the window manager — there is no protocol by which a second process places another's windows. This directory is to be deleted, and what it argues for survives as a module boundary inside Schcom rather than a process boundary.
See
docs/plan/wayland.md.
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.