diff options
| author | user <user@clank> | 2026-08-14 13:59:05 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-14 13:59:05 +0200 |
| commit | 4bb2bb5f05dda628722ae363fa4580aa69f37e7c (patch) | |
| tree | 4c06be8b88295a266405a9ec28e67993e4936fae /config/config.kdl | |
| parent | sl0ppty: drag greys the other panes, and dim_unfocused (diff) | |
| download | slosh-4bb2bb5f05dda628722ae363fa4580aa69f37e7c.tar.gz slosh-4bb2bb5f05dda628722ae363fa4580aa69f37e7c.tar.xz slosh-4bb2bb5f05dda628722ae363fa4580aa69f37e7c.zip | |
sl0ppty: dashed borders and a deeper push-back while dragging
Two changes to the same moment, on opposite sides of the chrome boundary.
Every pane that is not being dragged now draws a dashed border, because every
one of them is somewhere the pane could be dropped and a dashed frame says so
without needing a legend. The pane in your hand keeps a solid one, so the two
states are distinguishable by shape and not only by colour — which matters on
a terminal whose palette makes the greying subtle, and to anyone who would not
see the greying at all. The pane actually under the pointer still takes the
existing drop-target highlight on top of the dashes: these are all targets,
that one is the one you are on.
Borders are chrome, so this is not a shader and could not have been. It lives
in draw_frame, keyed off the same drag.moved that gates the greying, so a press
that turns out to be a click neither greys nor dashes anything.
The greying itself gets a second pass: desaturated *and* darkened, rather than
only desaturated. Grey alone still competes for attention at the same
brightness, which is what made the dragged pane fail to pop. Two shaders
instead of one that does both, because "colourless" and "recessed" are
different things to want and want separate knobs — drag_grayscale 200 and
drag_dim 140. This is the first thing to actually use the chain, and it is
what the chain was for.
The knob that used to mean "off" no longer does, and the test that asserted it
caught that immediately: drag_grayscale 0 now leaves drag_dim still dimming.
Rather than couple them, the test became three — both off, each alone — which
is better coverage of a two-knob effect than the single case was of a one-knob
one.
Diffstat (limited to '')
| -rw-r--r-- | config/config.kdl | 16 |
1 files changed, 12 insertions, 4 deletions
diff --git a/config/config.kdl b/config/config.kdl index f114719..4a71c38 100644 --- a/config/config.kdl +++ b/config/config.kdl @@ -64,11 +64,19 @@ double_click_ms 400 // fighting. 40 is a hint, 120 is obvious. dim_unfocused 0 -// While a pane is being dragged by its title, grey every *other* pane, so the -// one that is moving lifts off the page. Transient — it appears once the drag -// actually moves and is gone on release — so unlike the above it costs -// nothing when you are not doing it. +// While a pane is being dragged by its title, push every *other* pane back so +// the one that is moving lifts off the page: drag_grayscale drains its colour, +// drag_dim drops its brightness. Two knobs because "colourless" and "recessed" +// are different things to want, and grey alone still competes for attention at +// the same brightness. Transient — they appear once the drag actually moves and +// are gone on release — so unlike dim_unfocused they cost nothing when you are +// not dragging. Set both to 0 to turn the effect off. +// +// The dragged pane's border also stays solid while every other pane's turns +// dashed, marking them as places it could be dropped. That is chrome, not a +// shader, so it happens whatever these are set to. drag_grayscale 200 +drag_dim 140 // How long an announcement ("copied 13 chars", a pane's OSC 9 notification, // "config reloaded") stays in the bottom-right corner. |
