Fix Super+Arrow keyboard tiling: write to /xfwm4/custom/#24
Merged
kimptoc merged 2 commits intokimptoc:claude/fix-xfce-wallpaper-FK5rhfrom May 4, 2026
Conversation
The previous "move to /xfwm4/default/" theory (97c7365) was inverted. On this NixOS xfwm4 image /xfwm4/custom/override is true at first login, making "Custom" the live key theme — xfwm4 reads bindings only from /xfwm4/custom/ and silently ignores anything under /xfwm4/default/. xfconf accepted our default-tree writes, but xfwm4 never grabbed the keys: verified live with xev, which showed Super+Left flowing through to applications with state=Mod4Mask untouched (no XGrabKey installed for it). The stock <Super>KP_* numpad tile bindings ship in /xfwm4/custom/ already, which is why those always worked while the regular-arrow bindings we kept adding to default never did. Drop the -r reset dance (these regular-arrow paths don't pre-exist in /xfwm4/custom/ on a fresh boot, so plain -n create is sufficient and idempotent). Add per-binding readback echoed into the autostart log via a small bind_xfwm4 helper. The old "xfwm4 Super+Arrow tile keys bound" line was an unconditional echo, not a status check, which hid silent xfconf no-ops through three iterations of this fix. Future logs will show which bindings took and which didn't, in one place. Verified live by writing the same bindings to /xfwm4/custom/ via xfconf-query on a running ISO: Super+Left/Right tile, Super+Up maximises, Super+Down tiles bottom-half. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous attempt (3ebd971) wrote bindings to /xfwm4/custom/ correctly but 4 of 8 still silently failed to grab on a fresh boot. Two extra defenses make this reliable: 1. Delete the four /xfwm4/custom/<Super>KP_{Right,Down,End,Next} numpad siblings before writing our regular-arrow bindings. xfwm4 4.20 stores ONE binding per action enum (one slot in screen_info->params->keys[KEY_*]) — when two custom-tree paths point at the same tile_*_key, its runtime cb_shortcut_added installs only one grab, and not necessarily ours. Verified live with xev: with both <Super>Right and <Super>KP_Right pointing at tile_right_key, Super+Right reached applications with state= Mod4Mask untouched (no XGrabKey for it). Removing the numpad siblings is a non-regression — Code Club kit has no numpads. 2. Reset (-r) each target path before -n create. -n is no-op when the property already exists with ANY type, and we hit a case where /xfwm4/custom/<Super>Down had been promoted to an array [tile_down_key,tile_down_left_key] (origin unclear, likely from xfwm4-settings GUI fiddling on a previous live-CD test). xfwm4 silently can't parse arrays as bindings → no grab. -r before -n guarantees a clean string property. Verified the runtime equivalent of these two changes on the live ISO: deleting the four KP_* siblings, then -r/-n-rewriting the Super+Down array, made all 8 keyboard tiling combos fire correctly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two commits, both fixing the xfwm4 Super+Arrow keyboard tiling on the Code Club live CD. End-to-end verified on a real live-ISO boot — all 8 keyboard tile combos now fire correctly.
3ebd971— Write to/xfwm4/custom/, not/xfwm4/default/. The earlier "move to default" theory (97c7365) was inverted: this NixOS xfwm4 image has/xfwm4/custom/override = true, so Custom is the live key theme and xfwm4 silently ignores anything under default. Confirmed live withxev: Super+Left flowed through to applications withstate=Mod4Maskuntouched (noXGrabKeyinstalled). Adds per-binding readback into the autostart log so silent xfconf no-ops can't hide again.59d9307— Defuse stock numpad collisions, scrub stale types. Even after #1, 4 of 8 bindings (Right, Down, Ctrl+Left, Ctrl+Right) still silently failed to grab on a fresh boot. Two extra defenses:/xfwm4/custom/<Super>KP_{Right,Down,End,Next}numpad siblings before our writes. xfwm4 4.20 stores ONE binding per action enum (screen_info->params->keys[KEY_*]); when two custom-tree paths share atile_*_key, the runtimecb_shortcut_addedinstalls only one grab, and not necessarily ours. With both<Super>Rightand<Super>KP_Rightpointing attile_right_key, Super+Right ended up not grabbed at all. Code Club kit has no numpads, so removing the four sibling entries is a non-regression.-r) each target path before-ncreate.-nis no-op when the property exists with any type — and we hit a case where/xfwm4/custom/<Super>Downhad been promoted to an array[tile_down_key,tile_down_left_key](likely from xfwm4-settings GUI fiddling on a previous live-CD test). xfwm4 silently can't parse arrays as bindings → no grab.-rbefore-nguarantees a clean string property.Test plan
~/myautostart.logshows each/xfwm4/custom/<Super>...binding with its action value (the readback)🤖 Generated with Claude Code