<feed xmlns='http://www.w3.org/2005/Atom'>
<title>srdwm/crates/config/src/engine/mod.rs, branch main</title>
<subtitle>Cross-platform window manager written in Rust.
</subtitle>
<id>https://srdusr.com/git/srdwm/atom?h=main</id>
<link rel='self' href='https://srdusr.com/git/srdwm/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://srdusr.com/git/srdwm/'/>
<updated>2026-07-05T14:06:00+00:00</updated>
<entry>
<title>Let the config file take back a setting changed at runtime</title>
<updated>2026-07-05T14:06:00+00:00</updated>
<author>
<name>srdusr</name>
<email>99972264+srdusr@users.noreply.github.com</email>
</author>
<published>2026-07-05T14:06:00+00:00</published>
<link rel='alternate' type='text/html' href='https://srdusr.com/git/srdwm/commit/?id=744757fad22db7a5ebebca9a685cdb00589a1b02'/>
<id>urn:sha1:744757fad22db7a5ebebca9a685cdb00589a1b02</id>
<content type='text'>
Reported as windows still being tinted. The tint is the drop shadow, and
init.lua sets general.shadows to false - loading that same config in a
fresh compositor reports false, while the running session reported true.

The reason it could not be corrected is a defect in the live-settings replay
added earlier today. That replay re-applies every srd set after a config
reload so the titlebar menu's Customize rows survive a save. The unintended
half is that a live override then outranked the config file permanently:
editing init.lua and saving put the override straight back, which is the
state the session was found in.

Live-always-wins and config-always-wins are both wrong. The rule is now that
the config wins for anything it states, and a live override survives only
where the config is silent. That distinction cannot come from `values`,
where defaults are seeded before any script runs so every key looks set, so
the config engine records which keys srd.set actually touched during the
load. That record is cleared and rebuilt on each load and restored along
with everything else when a reload fails.

Verified both directions: a config-stated key reverts to the file's value on
the next reload, and a key the config never mentions keeps its live
override.

529 tests pass, clippy clean.
</content>
</entry>
<entry>
<title>Expose key bindings over IPC so a launcher can list them</title>
<updated>2026-05-13T17:47:00+00:00</updated>
<author>
<name>srdusr</name>
<email>99972264+srdusr@users.noreply.github.com</email>
</author>
<published>2026-05-13T17:47:00+00:00</published>
<link rel='alternate' type='text/html' href='https://srdusr.com/git/srdwm/commit/?id=670c9845129fc0c4b6e0192d657eea05e1a64b49'/>
<id>urn:sha1:670c9845129fc0c4b6e0192d657eea05e1a64b49</id>
<content type='text'>
Asked whether srdwm's bindings show in the AGS launcher. They could not:
srd.bind lives entirely in the Lua engine, and nothing published a binding
anywhere a client could read it. There was no IPC command, no field in any
response, and bound_keys() was used only by main.rs to register grabs.

srd.bind now takes an optional third argument, a description, and the loaded
set is copied into the WindowManager after the initial load and after every
reload. Core neither owns nor interprets them - it has no Lua state and
never dispatches a key - it holds them so the IPC layer, which is handed a
WindowManager and nothing else, can serve them. New `srd keybindings` returns
combo and description pairs, sorted so a UI listing them does not reshuffle
on every refresh.

Every binding in the shipped config now carries a description, so the feature
is useful without the user writing any.

Verified live in a nested instance: 46 bindings published, 0 without a
description, and editing the config file updated the list without a restart
(which also exercised reload-on-write again).

Also verified, for the separate report that windows cannot be moved to
another workspace from the AGS workspace pills: the compositor side works.
`srd dispatch move workspace &lt;id&gt; 2` moved a window from workspace 1 to 2 and
correctly hid it, since workspace 1 was active. Nothing to fix here; the
missing piece is on the shell side.

515 tests pass, clippy clean.
</content>
</entry>
<entry>
<title>Split crates/config/src/lib.rs (1441 lines) into engine/</title>
<updated>2024-07-29T12:01:00+00:00</updated>
<author>
<name>srdusr</name>
<email>99972264+srdusr@users.noreply.github.com</email>
</author>
<published>2024-07-29T12:01:00+00:00</published>
<link rel='alternate' type='text/html' href='https://srdusr.com/git/srdwm/commit/?id=5fe599437ab9d1d9cfa749e861ce2f3acc02aa3c'/>
<id>urn:sha1:5fe599437ab9d1d9cfa749e861ce2f3acc02aa3c</id>
<content type='text'>
Pure reorganization, no behavior change - verified by diffing the
function-name and struct/enum-name sets before/after (both identical)
plus a full cargo test pass. lib.rs is now a thin shim (mod
declarations + pub use) since a crate root can't itself become a
directory; all the actual content moved into engine/, split along the
Lua API's own srd.*/srd.window.*/srd.layout.*/srd.workspace.*/
srd.theme.* namespace groupings the file's own section comments
already used:

- mod.rs: SharedState, Engine, ConfigError, and Engine's core methods
  (new/get/set/dispatch/reload/...).
- register.rs: register_srd_module, which wires every fn_* builder
  from every other file into the srd Lua table - the one place that
  genuinely needs to see all of them.
- general.rs/window.rs/layout.rs/workspace.rs/theme.rs: the fn_*
  builder methods themselves, one file per srd.* sub-namespace.
- support.rs: free functions shared across those (do_reload,
  parse_direction, flatten_table_into, validate, default_config) and
  the WindowAction enum.
- tests.rs: the ~300-line test module, left unsplit for the same
  shared-helper reason manager/tests.rs and udev's tests were.

~40 fn_* methods and the support.rs free functions/enum went from
private to pub(super): called across what are now sibling submodules,
which Rust's privacy model doesn't let see each other's private items.
</content>
</entry>
</feed>
