sl0ppty: modals get their own surface, and dim what is behind them

Two things wrong with the first one, and both are about it being a modal
rather than a pane that happens to float.

The close button was invisible. It was drawn in the pane button colour on the
finder background, and in the default theme those are the same value --
#45454a on #45454a -- so it only appeared when the pointer landed on it and
the hover colour took over. That is the hazard of borrowing names from
another surface: each one is right, and together they are nothing. A modal is
its own surface now, with its own names (modal_bg, modal_fg, modal_border,
modal_title, modal_button, modal_button_hover), a dark panel a shade lighter
than the dimmed screen, a border in the accent, and a button chosen to be
visible *without* the pointer on it. All six themes set them.

And nothing behind it moved, so it read as another pane rather than as
something in front. There is a scrim now, `modal_scrim` (0..255, 120 by
default), and the pleasing part is that it is not a new mechanism: it is the
shader pass aimed at the screen instead of at a pane. Same dim, same
materialisation of default colours, no special case. It goes down after
everything else is painted and before the modal, so the modal is the only
thing at full brightness -- which is the whole idea, and is asserted rather
than assumed.

The shape is now reusable: modal_frame() draws the box, title, close button
and hit, and returns the rect inside it; draw_scrim() is one line above it.
The next modal is a function call and looks the same as this one.

The finder is deliberately left alone. It is a picker rather than a modal --
it navigates, where a modal here dismisses on any key -- so unifying them
would be making two things one because they are both rectangles.

1 files changed, 23 insertions, 0 deletions

diff --git a/config/config.kdl b/config/config.kdl
index dd50cdd..bfeebb6 100644
--- a/config/config.kdl
+++ b/config/config.kdl
@@ -163,6 +163,16 @@ hover_delay_ms 250
 // program calls itself.
 double_click_ms 400
 
+// How far everything behind a modal (the cheatsheet, C-a ?) is pushed back,
+// 0..255, and 0 for not at all. A modal floating over a screen as bright as
+// it is reads as another pane rather than as something in front.
+//
+// It is the shader pass aimed at the whole screen, so the same caveat applies
+// as for shaders: cells with no colour of their own are resolved through
+// theme's default_fg/default_bg first, and if those do not match your
+// terminal's real colours the screen will shift slightly while a modal is up.
+modal_scrim 120
+
 // Extra shaders can be loaded from shared libraries: any `*.so` in the
 // directory below that exports a sl0ppty shader plugin. Once loaded they are
 // named here exactly like a built-in. Default: a `shaders` directory beside
@@ -382,6 +392,19 @@ theme {
     minbar "#45454a"
     minbar_hover "#ff5fd7"
 
+    // ── modals: a surface that floats over the layout ───────────────────────
+    // Named apart from the pane colours they resemble because a modal is a
+    // different surface: opaque, on top of everything, and legible against a
+    // background that has been dimmed underneath it. (The first version drew
+    // the close button in the pane button colour on the finder background,
+    // which are the same value — an invisible button until you hovered it.)
+    modal_bg "#1c1c22"          // a shade lighter than the dimmed screen
+    modal_fg "#e8e8ea"
+    modal_border "#ff5fd7"
+    modal_title "#ffffff"
+    modal_button "#8a8a95"      // visible *without* the pointer on it
+    modal_button_hover "#ff5fd7"
+
     // ── the pane finder ─────────────────────────────────────────────────────
     finder_fg "#ffffff"
     finder_bg "#45454a"