Summary: | Window rules editing broken | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Duncan <1i5t5.duncan> |
Component: | rules | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cfeck, matejm98mthw |
Priority: | NOR | Keywords: | regression, reproducible |
Version: | git master | Flags: | mgraesslin:
Wayland+
mgraesslin: X11+ mgraesslin: ReviewRequest+ |
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://phabricator.kde.org/D12706 | ||
Latest Commit: | https://commits.kde.org/kwin/bed31e0557854bb92425db1eab73022c41f2c793 | Version Fixed In: | 5.13.0 |
Description
Duncan
2018-05-03 05:44:16 UTC
Which KWin version are you using? I consider it very unlikely that such a central part of KWin could be broken. I at least created a window rule on X11 today. (In reply to Martin Flöser from comment #1) > Which KWin version are you using? All of kde/plasma/frameworks is live-git. kwin --version reports 5.12.80, and git show in kwin's repo reports c0226fe74 from Apr 26, but as I said it has been at least a few weeks because (see original report). > I consider it very unlikely that such a > central part of KWin could be broken. I at least created a window rule on > X11 today. Did it actually apply and save? Note that I can create and change rules, and hitting OK on the individual rule dialog and then apply in the kcm /appears/ to create and save it -- no visible errors -- but it doesn't actually get saved or affect the window it's supposed to, either -- when I switch to a different kcm and back to reload, the edited rule is just as it was before the edit, and new rules simply aren't there any more. What I'm /wondering/ is if whatever framework actually saves the changes changed out from under the API the kcm is using to invoke it and the kcm wasn't synced to the changes, with the changes not enough to error out, just enough so the save isn't happening (or maybe it is but to a different location, so it's written to one but read from another). What framework might that be? I might try rolling it back a couple months and see if it makes a difference. Of course if I knew which one I could report specific git commit on it then as well. There are a few non-default factors in my setup that could be involved as well. In particular, I have KDEHOME, KDETMP, KDEVARTMP, XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME set. If there's a hard-coded path (maybe a place where the default path isn't overridden in the var is set) or one using a different var for read vs. write, it would lead to exactly this sort of symptoms, that would likely not duplicate at all on a system with these vars unset so it uses the default settings. From konsole (so with the KDE/X env): $ export | grep 'KDE\|XDG\|HOME' declare -x HOME="/h/x" declare -x KDEHOME="/h/x/kde" declare -x KDETMP="/h/x/tmp/kde" declare -x KDEVARTMP="/h/x/tmp/cache" declare -x KDE_FULL_SESSION="true" declare -x KDE_NO_IPV6="1" declare -x KDE_SESSION_UID="501" declare -x KDE_SESSION_VERSION="5" declare -x KDE_UTF8_FILENAMES="1" declare -x PROFILEHOME="~" declare -x XDG_CACHE_HOME="/h/x/tmp/cache" declare -x XDG_CONFIG_DIRS="/etc/xdg" declare -x XDG_CONFIG_HOME="/h/x/config" declare -x XDG_CURRENT_DESKTOP="KDE" declare -x XDG_DATA_DIRS="/usr/local/share:/usr/share" declare -x XDG_DATA_HOME="/h/x/config/share" declare -x XDG_RUNTIME_DIR="/run/user/501" declare -x XDG_SEAT="seat0" declare -x XDG_SESSION_ID="c1" declare -x XDG_VTNR="1" Ok, master makes more sense: there we do have changes. I found the change which introduced the regression and have a patch for it: https://phabricator.kde.org/D12706 Luckily it's only in master branch. (In reply to Martin Flöser from comment #4) > I found the change which introduced the regression and have a patch for it: > https://phabricator.kde.org/D12706 > > Luckily it's only in master branch. Applied locally and confirmed that it fixes the bug here. Nice to have new rule changes working again! Lots easier than editing the file manually! Thanks. Looking forward to seeing it in git after review. =:^) Thanks for testing Git commit bed31e0557854bb92425db1eab73022c41f2c793 by Martin Flöser. Committed on 20/05/2018 at 13:43. Pushed by graesslin into branch 'Plasma/5.13'. Reparse rules config prior to update Summary: We used to recreate the KConfig when rules needed to update. Now that it is a KSharedConfig, which is kept, it needs to be reparsed as it changes outside of KWin. FIXED-IN: 5.13.0 Test Plan: Restarted session, changing rules work again Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D12706 M +2 -0 rules.cpp https://commits.kde.org/kwin/bed31e0557854bb92425db1eab73022c41f2c793 *** Bug 394488 has been marked as a duplicate of this bug. *** |