hq/01-RESEARCH/026-the-graphical-session-as-modules/02-the-questions-and-the-options.md

02 — The questions and the options

Seven questions. Each has its options and a starting position, which is what this effort tests, not what it has decided.

1. How finely the desktop splits into modules

	option	for	against
G1	One desktop module, as the predecessor had	one assignment	flavors again, per machine; ADR 0174 refuses them, and the evidence shows a flavor landing on the wrong machine
G2	One module per piece of software: lemurs, xorg, i3, i3status-rust, xterm, picom, rofi, dunst, xss-lock with the lock screen, greenclip, feh, a theme module, a fonts module	each is what it declares; a machine gets exactly what is assigned; the same split already works for the shell and its plugins	about thirteen assignments per workstation
G3	G2, plus a named set the controller assigns as one (for example the X desktop)	G2's precision with G1's convenience	a set is a new controller concept

Starting position: G2. Whether a set is worth a record is left until the thirteen assignments have been done by hand once.

2. The seats

Research 018 listed the candidates. ADR 0204 has since put the login shell in the mesh's own set, because a role with a protocol should not depend on one module's registration. The same reasoning applies here:

seat	holders	protocol, first verbs
node-login-manager	lemurs, greetd	which sessions it offers, the default session
node-display-server	xorg, sway	displays, layout
node-display-session	i3, sway	reload, workspaces, windows
node-terminal-emulator	xterm, foot, alacritty	which terminal $TERMINAL names; open
node-bar, node-compositor, node-launcher, node-notifier, node-lock-screen, node-clipboard	the pieces above, and their Wayland counterparts	one verb or none each, until a use asks for one

A compositor that is its own server holds two seats. Sway is both the display server and the display session. A module may claim several seats, so this needs nothing new.

Starting position: the first four seats are in the mesh's own set. The companion seats are added only as each holder is written; for those, a module without a seat is acceptable at first.

3. One module requiring another seat to be held

i3 needs an X server held on its node, and sway needs nothing below it. A terminal needs a session. To-be 37 left open how that is said.

	option	for	against
R1	A seat delivers a provision (x11-display, wayland-display) and a module requires it at node scope. The seat table has a delivers field already, and requirements already resolve	existing machinery; the refusal names the seat and its possible holders, which design 27 already lists	a node-scoped requirement that never crosses machines has to be stated as such
R2	A new field, needs the seat X held	reads plainly	a second way to say what R1 says
R3	Nothing; assign carefully	—	the mistake the evidence shows (a laptop's fragments on a desktop) is exactly an unchecked assignment

Starting position: R1. xorg and sway each deliver what they serve. i3, picom and xss-lock require x11-display. foot requires a Wayland display, and xterm requires an X one, which a Wayland session gives through xwayland.

4. Who starts the session, and with what environment

Today ~/.xinitrc is a hand-kept second environment and the session's whole start script.

	option	for	against
S1	The display server's module writes ~/.xinitrc into: a mesh block at the start that sources the account's environment (environment.sh), merges the X resources, and runs the session's contributed start lines. The session holder's module contributes its exec line. The operator's lines stay after the block	one environment for shells, the session and the user manager; nothing to keep in step	the order inside .xinitrc becomes the slot order of a contribution (question 5)
S2	The login manager's module owns the session script under /etc	system scope; no home file	the environment is the account's, and the script is the same for every account
S3	Leave .xinitrc the operator's	nothing to build	the third environment stays

Starting position: S1.

• The desktop's identity (XDG_CURRENT_DESKTOP) and the theme variables become environment contributions (ADR 0203) from i3 and from the theme module. They then also reach the user manager through environment.d, which replaces most of today's allowlist import.
• The secrets file stays out of the environment until research 027 settles how a secret reaches an account.

5. How other modules contribute to a holder's file

The terminal's settings are X resources. A bar, a launcher binding and a hardware module's key bindings are window-manager configuration. Autostarts are the session's. ADR 0204 built slot contributions for shells only.

	option	for	against
C1	The tool's own drop-in directory, where it has one: i3's include, dunst's dunstrc.d, X resources' #include, XDG autostart entries, environment.d. Each contributor owns its own file there	no mesh change; the tools already read these directories; unassigning removes the file	each contributor names a path in another tool's directory (ADR 0204 rejected this for shells, where no drop-in convention exists); ordering is by file name
C2	ADR 0204's mechanism generalised: contributes text for a format (zsh, xresources, i3, xinitrc) in a slot, placed by the holder's placeholder	one mechanism, checked by the controller, order declared	every format must be named in the controller; a bigger change to ADR 0204
C3	C1 where the tool has a drop-in convention, C2 where it does not (.xinitrc, .Xresources order)	uses each tool's own grain	two mechanisms to learn

Starting position: C3, with the boundary drawn by the tools. A tool that reads a directory gets drop-ins. A file without one gets slots. This means amending ADR 0204's "shell" to "a format", which is a progressive extension rather than a reversal.

6. What varies per machine

what	today	option
monitor layout	per-machine xrandr scripts, monitor names baked in	a setting of xorg (issue 168), and a layout verb of the display server seat
DPI, fonts' size	fixed in an X resource	a setting
battery block, vendor keys, brightness, touchpad	a laptop model's flavor	a hardware module per machine model, contributing its window-manager fragment, bar block and udev rules. The desktop simply is not assigned it
theme (the 105 variables)	template substitution	settings of each tool's module, after issue 168 closes (ADR 0174). Until then each module carries today's values as its default

Starting position:

• Hardware modules for what follows the machine.
• Defaults now, settings after issue 168, for what the operator varies.
• The monitor layout waits for settings. Until then it is an operator-owned script the display server's block calls if present.

7. Wayland and sway

Nothing of a Wayland session exists, and every piece is officially packaged. "Wayland" is a protocol, not a piece of software, so it has no module of its own. Its parts are sway (server and session), swaylock, foot, waybar, mako, and xwayland for X clients.

Starting position:

• The seats and the requirements (questions 2 and 3) are designed so that sway fits from the first day.
• The X stack is built first, because it is what runs.
• sway and its companions are written after that, and proven on one workstation as a second session the login manager offers beside i3. That lets the operator try it without losing the working desktop.

Prerequisites this effort cannot remove

• User-scoped units (mesh-host #72) for the reload watcher and the bar watchdog.
• Settings (issue 168) for monitors and theme values.
• The two packages not in the official repositories: the lock screen's colour build and the clipboard manager. Each is ADR 0205's case, a pinned archive, or a choice of an official alternative (i3lock without colours; clipmenu/cliphist).