aboutsummaryrefslogtreecommitdiffstats
path: root/web/demo/overlay (follow)
Commit message (Collapse)AuthorAge
* webdemo: the picker in the machine, and a guest that proves its themesuser2026-09-22
| | | | | | | | | | | | | | | | | | | | | | The demo image was cut before any of this existed: an old guest binary with no `C-a t` in it, and a config whose theme was a pasted palette. Rebuilt -- guest binary, root filesystem, site -- so the thing a visitor lands in is the thing the front page is now claiming. The overlay already kept every shipped theme in ~/.config/slosh/themes (they are symlinks into contrib/, copied by content because a symlink in an ext2 image would dangle), which turns out to be exactly the directory the picker looks in first -- and in the guest it is the *only* one, since /usr/bin/slosh has no share/slosh beside it. So `boot-check` now asks the guest itself: `{"cmd":"theme"}` over --script, expecting the worn theme and the shipped list back. It failed honestly the first time, for the right reason (no HOME in a phase that boots straight to /bin/sh, so no config, so no themes/ beside it), which is the kind of failure a check is for. The welcome float grew a fourth line -- `C-a t`, every theme, worn as you browse -- and a row to hold it; the motd and the config's own comments say the same. A visitor who reads three lines and presses one key should land on the feature the page just sold them.
* theme: a name and a directory, not sixty colours in your configuser2026-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wearing a theme meant pasting its `theme { }` block into config.kdl, or including a path to a file you had copied there yourself. Both make the palette a literal in your config, and a literal is the one thing you cannot change cheaply: not from a script, not from a running session, not by a list of what is available, and never again from upstream -- the colours you pasted are the colours that theme had the day you pasted them. So a theme is a file in a directory now, and a config names it: theme_name "phosphor" theme { frame_focus "#00ff88" } // ...but that one colour is mine theme_name is applied after the includes and before everything the file says itself, which is the rule includes already follow and for the same reason: the loader reads a document by asking it for names rather than walking it in order, so "here" is not a position it could honour, and "what you asked for is the base, what you wrote is yours" is the rule worth having. Two directories, yours first: `themes/` beside the root config -- beside the file that was loaded, so a config somewhere else (SLOSH_CONFIG, or one handed to --check) takes its themes with it -- and then <prefix>/share/slosh/themes, compiled in from PREFIX. install(1) has been putting themes there all along and nothing could read them; now a shipped theme is nameable without being copied, and a file of yours with the same name shadows it, which is how a root-owned theme gets edited. A name, not a path. The directory is what makes a theme switchable, listable and shadowable, and a path silently does none of those, so `theme_name "../x.kdl"` is refused with a line pointing at `include`, which still works and is still the answer for a file somewhere a directory of names cannot reach. A theme that is not there is one complaint and no more (D9): the rest of the config applies, because losing your keybindings over a mistyped colour scheme would be the wrong trade. A theme file is read by the same loader, so it is watched like any other: saving one reloads the session wearing it, and the derivations (tab_status_fg, tab_idle_bg) run over the theme's own colours exactly as before. Switching without editing anything, over the socket a session already has: slosh -s main cmd theme # amber default* ... slosh -s main cmd '{"cmd":"theme","name":"amber"}' # now slosh -s main cmd '{"cmd":"theme","name":"amber","save":true}' The session holds the name over later reloads, so saving your config for an unrelated reason does not put the old colours back; `save` writes the theme_name line into the file, replacing the one already there and leaving every other line and comment alone -- dumping the whole config back over itself would reformat a hand-written file and drop its comments, which is not a fair price for changing a colour scheme. A name is tried on a throwaway config first, so a typo costs nothing. An empty name gives the answer back to the file. --dump-config stops writing colours: it writes the theme's name and the colours a config overrode by hand, so a dumped config keeps following its theme instead of freezing it. --dump-theme is the other half and is new: the resolved palette as a theme file, which is how you start one from the session in front of you rather than from an empty file. It is also what keeps contrib/themes/default.kdl honest -- that file is now the annotated reference (the commented palette moved there out of config.kdl, where it was 119 lines of colour in the middle of the prose), and a test compares it against the compiled-in one. While in there: tests/test_themes.py's "every theme sets every colour" guard had been grepping for `&c->`, the spelling before the colour table moved to offsetof, so it had been finding zero colours and passing for months. Fixed, with the derived and opt-in colours exempted for the reasons they are derived and opt-in, and with a check that the guard found a table at all.
* webdemo: no attach splash -- the welcome float already greetsuser2026-08-30
| | | | | | | Two logos in quick succession -- the splash's, then the welcome float's -- reads as a glitch, not a greeting, technically correct or not. splash_ms 0 in the guest config; the comment leaves the knob visible for anyone editing their way through the playground.
* webdemo: land in the playground, not just the demouser2026-08-30
| | | | | | | | | | | | | | | | | | | | The overlay grows into a first session worth having: - The config is a playground now -- every theme the repo ships rides along as an include one word away, and the settings worth flipping (compact, shaders, keys, dim_unfocused) sit commented in the file, each one uncomment-and-save from happening on screen. - C-a e opens vim, not busybox vi: editor "vim" in the config, since the image always carried the real vim and its kdl syntax without ever launching them. shortmess in the vimrc keeps the file-info message from wedging a narrow pane into a hit-enter prompt. - The config starts open, highlighted, in a pane of its own: the discovery C-a e would make, made before anyone has to make it. - A welcome float greets over everything, the slosh logo on top, centred by the layout engine at whatever size the browser gave the terminal (the previous commit is its enabling act). It teaches its own dismissal -- C-a x, or the X it wears -- and it never exits on its own, so keep_dead has no corpse to keep.
* slosh: the website lives in web/ -- one directory, one build, make wwwuser2026-08-19
Consolidate everything the website is made of: - web_new/ -> web/: the front page, install.sh, and build-site - contrib/webdemo/ -> web/demo/: the in-browser machine, committed for the first time (it had never been checked in) - make www at the top level assembles the whole site into build/www (NO_DEMO=1 skips the guest cross-compile) - web_plan.md deleted: the plan is fulfilled and web/README.md is now the record Path fallout: the overlay theme symlink gains one ../ (web/demo is a level shallower relative to contrib/themes), PYSRC in the Makefile follows the demo scripts, contrib/README.md drops its webdemo section. ROOT := ../.. in the demo Makefile survives unchanged -- web/demo sits at the same depth contrib/webdemo did. Verified: make www builds front page + docs + demo end to end, web/demo make check boots the image to slosh, tests/test_docs.py and make fmt-check green.