Persist per-screen/per-desktop layout assignment across sessions - #212
Open
reg3x wants to merge 1 commit into
Open
Persist per-screen/per-desktop layout assignment across sessions#212reg3x wants to merge 1 commit into
reg3x wants to merge 1 commit into
Conversation
trackLayoutPerScreen and trackLayoutPerDesktop only tracked the active layout for each screen/desktop in memory (the screenLayouts property), with nothing to load or save it. Every KWin restart reset all screens/desktops back to layout 0, so multi-monitor users had to manually reassign each screen's layout every login. KWin.writeConfig isn't available to scripts (only effects), so this persists screenLayouts via QML's own Settings type (QtCore module) instead, which is independent of KWin's config API. Also bounds-checks the restored layout index in getCurrentLayout() so a stale value (e.g. after layouts are edited or removed) falls back to 0 instead of returning an out-of-range index. Tested against the 0.9.2 release structure with a full reboot on a 2-monitor setup (one normal, one rotated 90 degrees) - each screen came back on its previously-assigned layout. This patch targets main's current refactored structure (getLayoutKey/trackLayoutPerDesktop), confirmed with qmlformat and a clean build, but not independently re-verified live against main's exact code since loading a second script instance risks colliding with global shortcuts from an already-running kzones session.
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.
Problem
With
trackLayoutPerScreenortrackLayoutPerDesktopenabled, each screen/desktop's active layout is only tracked in the in-memoryscreenLayoutsproperty. Nothing loads or saves it, so every KWin restart (login/reboot) resets everything back to layout index 0 — multi-monitor users have to manually reassign each screen's layout every session.Why not
KWin.writeConfig?That's the obvious first approach, but it doesn't exist for KWin scripts — only KWin effects get a writable config API. Calling it throws a runtime
TypeError(confirmed viajournalctl). This is a hard platform limitation for scripts, not an oversight.Fix
Persist
screenLayoutsusing QML's ownSettingstype (QtCoremodule) instead, which is independent of KWin's config API. Also bounds-checks the restored layout index ingetCurrentLayout()so a stale value (e.g. after layouts are edited/removed) falls back to 0 instead of returning something out of range.Testing
Verified across a full reboot on a real 2-monitor setup (one normal, one rotated 90°), tested against the 0.9.2 release's code structure — each screen came back on its previously-assigned layout with no manual intervention. This PR ports the same fix onto
main's current refactored structure (getLayoutKey()/trackLayoutPerDesktop), confirmed withqmlformatand a cleanmake build, but not independently re-verified live againstmainspecifically — loading a second script instance for testing risks colliding with global shortcuts from an already-running kzones session, so I didn't want to test on my live daily setup. Flagging this so it gets a real functional pass from CI/review before merge.