Apply a profile when active-profile is written externally - #3
Merged
Conversation
Only the preferences process listened to this key, and only to refresh its own UI — so another program could set it and nothing happened on screen. Wiring it in `enable()` turns the key into a real entry point: writing it with gsettings applies the profile, which lets an external program drive the borders without knowing the nine appearance keys or duplicating the per-camera calibration. The calibration stays here, where it belongs. No feedback loop: `applyProfile` writes the key back with the same value, and GSettings does not emit `changed` when the value is unchanged. The handler is disconnected in `disable()` alongside the existing ones. Note: on Wayland the GNOME Shell cannot reload an extension, so this only takes effect after logout/login. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The `active-profile` change turns gsettings into a real entry point, but a capability nobody can find is not a capability. Adds a README section with commands that were run on a live install, not written from memory: - `--schemadir` is required, because an extension's schema is not in the default search path. Omitting it fails with "No such schema". - Profile ids are UUIDs generated at creation, so the section shows how to look one up by name and says not to hardcode it. - The `profiles` key holds a JSON document wrapped in a GVariant string, which is why the example pipes through sed before jq. Also warns about the two things that cost real debugging time: auto-switch competing with an external controller for the same state, and Wayland needing a logout for code changes (settings changes apply immediately). Co-Authored-By: Claude Opus 5 (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
1 participant
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.
What
Wires
changed::active-profileinenable()so that writing the key from outsidethe extension applies that profile, and documents the capability in the README.
Why
The key already existed, but only the preferences process listened to it — and only
to refresh its own UI. An external program could set
active-profileand nothinghappened on screen, which made the key look like an entry point without being one.
The other appearance keys (
thickness-*,opacity,color,temperature,multi-monitor,maximize-brightness) are already picked up by the existingchangedhandler overSYNC_KEYS.active-profilewas the gap.This closes it, so another program can drive the borders by naming a profile instead
of reimplementing the nine appearance keys. The calibration stays in Lighter, where
it belongs — the caller says which, the extension says how.
No feedback loop
applyProfilewritesactive-profileback with the same value, and GSettings doesnot emit
changedwhen the value is unchanged. The handler is disconnected indisable()alongside the existing ones.Docs
New README section, written from commands run against a live install:
--schemadiris required — an extension's schema is not in the default searchpath, and omitting it fails with "No such schema".
one up by name and explicitly says not to hardcode it.
profileskey holds a JSON document wrapped in a GVariant string, which is whythe example pipes through
sedbeforejq.It also warns about the two things that cost real debugging time: Auto-switch
profiles competing with an external controller over the same state, and Wayland
needing a logout/login for code changes (settings changes apply immediately).
Testing
make lintpasses. The runtime behaviour is not yet verified on a live session:on Wayland the GNOME Shell cannot reload an extension, so this only takes effect
after logout/login. What is verified is that the settings path works — reading and
writing the keys with
gsettings, and resolving a profile id by name, were both runsuccessfully against the installed copy.
🤖 Generated with Claude Code