| Summary: | Kwin Window Rules working initially but get deleted after some time | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | laxmanpradhan |
| Component: | rules | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | kde |
| Priority: | NOR | ||
| Version First Reported In: | 5.14.4 | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Kwin Window Rules Files
This is the kwinrulesrc file when the rules are no longer working |
||
|
Description
laxmanpradhan
2018-12-14 22:08:28 UTC
please attach both a working and a broken kwinrulesrc Created attachment 116970 [details]
Kwin Window Rules Files
These are all the rules I am using, I import them into the Window Rules via the GUI. All of the rules work, initially, after a time some of the rules stop working. If I reimport the rules, they start working again. Which ones stop working seems to be random.
Created attachment 116971 [details]
This is the kwinrulesrc file when the rules are no longer working
Notice the [Oscar - Main] rule is no longer present and it is not working.
The rules in the first attachment look slightly wrong to me. The groups should be [1] and there should be a General section. In the second file what strikes me as odd is XftSubPixel[$d] and similar. These should not be there and I don't know how they get in there. I just tried erasing the kwinrulesrc file, then reimporting just my rules from the first file. The [general[ and [kde] part got added in again, same as before. Also within a few minutes the [Oscar -Labs] rules was releted from the kwinrulesrc file and stopped working. Re-importing all my rules again and it works again. >These should not be there and I don't know how they get in there.
These keys presumably exist in the global defualts (probably /etc/kde5rc)
Our code must be wiping the group. KConfig writes adds a marker rather than deleting the local entry so that it knows to override them with the face that they're deleted.
We probably want:
KConfig cfg("kwinrulesrc", NoGlobals);
Which I can do now.
Though fixing this won't apply retro-actively to broken configs.
*When KConfig writes it adds a marker rather than deleting the local entry so that it knows to override them with the fact that they're deleted. Do I see correctly that you use force temporarily rules? Git commit f3060723e126909a19d221401a473d4e2d3999b7 by David Edmundson. Committed on 19/12/2018 at 13:07. Pushed by davidedmundson into branch 'master'. [kcmkwin/kwinrules] Don't include kdeglobals in rules config Summary: There's nothing relevant in kdeglobals and loading it can lead to noise when deleting groups that override a system default. We still cascade which will allow kiosk keys to work as well as relevant system defaults. Import/Export is unchanged as that already uses SimpleConfig which includes this flag. I don't know if it will fix the relevant issue in the bug or just reduce noise. Test Plan: Compiled. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17645 M +1 -1 data/update_default_rules.cpp M +1 -1 kcmkwin/kwinrules/kcm.cpp M +2 -2 kcmkwin/kwinrules/main.cpp https://commits.kde.org/kwin/f3060723e126909a19d221401a473d4e2d3999b7 >Do I see correctly that you use force temporarily rules?
Yes, I wanted the behaviour to be that when the window first opens, it triggers the resize and reposition based on the rules, but then after than I wanted to still be able to move the windows around and resize them manually. I went through all the options and could not get it to work that way, with force temporary the windows were getting set according to the rules but then the rules were being 'erased'.
Over the last week I changed all my rules to 'force' and I haven't had the problem with the rules getting erased or forgotten. It was been working perfectly as it should.
So it seems like the issue is with 'force temporary' rules.
(In reply to laxmanpradhan from comment #10) > Yes, I wanted the behaviour to be that when the window first opens, it > triggers the resize and reposition based on the rules, but then after than I > wanted to still be able to move the windows around and resize them manually. > I went through all the options and could not get it to work that way, with > force temporary the windows were getting set according to the rules but then > the rules were being 'erased'. You should use "Apply Initially" rules for that purpose. > So it seems like the issue is with 'force temporary' rules. No, they work as expected. Marking as NOT A BUG per comment 11. |