Bug 421055 - [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
Summary: [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KC...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: rules (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Ismael Asensio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-05 12:24 UTC by Duncan
Modified: 2020-05-22 02:05 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.19.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan 2020-05-05 12:24:49 UTC
Since the window rules kcm redesign in ao4b40dad (or my first update after that anyway, pretty close), none of the normal-mode window sizing rules, size, minimum size, maximum size, seem to work at all, in X at least.  (Other geometry-related rules such as position and maximize-horizontally/vertically continue to work just fine.)

I have dual 75-inch/1.9m 4K TVs as monitors so have a /lot/ of screen real estate.  In normal operations I'll run a fullscreen youtube or the like on one monitor, while my normal work goes on the other one.  I've standardized most of my normal working apps, firefox (when not full-screened), often multiple konsole windows, claws for mail and feeds, pan for news (nntp), kpat and ksudoku for games, and an always-open ksysguard in the corner, to 1280x1080, thus letting me tile my working windows in a 3x2=6 grid across the "working" monitor, with the 1280x1080 sizes enforced as necessary by appropriate window rules.

Only now none of that size enforcement is working and it's playing havoc with my  grid setup. =:^(

There's a potential hint at the problem in that loading up existing window rules in the new kcm, the size rules are there, but with the sizes all zeroed out.  If I hit detect, the values fill in, but hit apply (with no actual window sizes changing if they were changed), leave the ruleset and come back to it, and the values are zeroed out again.

Further, checking the kwinrulesrc file, the size values for anything I've changed in the kcm are apparently reset to defaults, 0 for size and min/max values for those, 1 for min, 32767 for max, and the zeroed-out sizes are apparently deleted/not-stored.  Some of the ones I've not changed remain as they were in kwinrulesrc, but a couple, firefox and claws in particular as those are where I noticed the rules misbehaving and went to check-on/adjust, are screwed up.

So it appears the default values are overriding the actually set values once the individual window ruleset is loaded into the kcm, and that gets written back to the kwinrulesrc file.

Something also triggered the window rulesets for claws and firefox to misbehave causing me to visit their rulesets in the kcm in the first place, as well, but I'm not sure if that was kwin's fault or not, while I do know that once a change is made in the kcm, the sizes get broken, and that it was working before the kcm redesign.

kde-frameworks and kde-plasma are git master.  Current qt is 5.15.0-beta4.  xorg-server-1.20.8, mesa-20.0.6, xf86-video-amdgpu, kernel 5.7-rcs (but 5.6.0  does it too).  Current kwin was updated with today's update, to d5e5e2f1c, after which I did the usual quit X/plasma, restart updated services, remount root ro again, and restart X/plasma, dance.
Comment 1 Nate Graham 2020-05-07 13:47:17 UTC
Ismael, can you take a look?
Comment 2 Ismael Asensio 2020-05-14 19:45:05 UTC
I can reproduce it. 
Two changes went on since the last release (the QML frontend, and the KConfigXT backend), and I think this is something in the interface in-between. I'm on it.
Thanks for the report!
Comment 3 Ismael Asensio 2020-05-14 22:08:30 UTC
Proposed patch: https://phabricator.kde.org/D29764
Comment 4 Duncan 2020-05-14 23:45:42 UTC
(In reply to Ismael Asensio from comment #3)
> Proposed patch: https://phabricator.kde.org/D29764

Confirming, that patch works for me. =:^)

Tried loading an existing rule and the size parameters loaded.  Changing something and saving, they saved, and reloading, they loaded again.  Additionally, setup a new rule and it saved and worked.  So looks like that fixes it. =:^)

(Testing this I've become aware of 2-3 other bugs and/or "unwanted behavior changes" that might otherwise be considered "new features", but I'll file those separately as they're not /this/ bug (and FWIW don't seem quite as breaking).)
Comment 5 Ismael Asensio 2020-05-15 17:58:31 UTC
Git commit db7fb26eedcac7effd908e34579cf2fa422ac22b by Ismael Asensio.
Committed on 15/05/2020 at 17:45.
Pushed by iasensio into branch 'Plasma/5.19'.

[kcm/kwinrules] Fix size properties not being stored

Summary:
Use `QSize`/`QPoint` to handle and store coordinate values (size and position)

Previously, the rules model stored the "coordinate" type properties as a
`QString` with format `x, y`.

This fails when setting the properties to the config schema, as it requires
a proper `QPoint` or `QSize` value, specially the latter which can't be
convert from such a string.
FIXED-IN: 5.19.0

Test Plan:
- Add a new rule and set its position and size properties
- Hitting apply stores the right values in `~\.config\kwinrulesrc`
- Close the kcm and reopen, the values are loaded
- Property detection still works for size and position

Please note that there is a pre-existing bug of some position/sizes not being
applied to the windows in some cases, when using `Apply Initially`.
Better try using the `Force` policy.

Reviewers: ngraham, #kwin, #plasma, zzag

Reviewed By: #kwin, #plasma, zzag

Subscribers: zzag, ltoscano, yurchor, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D29764

M  +4    -3    kcmkwin/kwinrules/package/contents/ui/RulesEditor.qml
M  +7    -6    kcmkwin/kwinrules/package/contents/ui/ValueEditor.qml
M  +4    -5    kcmkwin/kwinrules/ruleitem.cpp
M  +2    -1    kcmkwin/kwinrules/ruleitem.h
M  +6    -8    kcmkwin/kwinrules/rulesmodel.cpp

https://commits.kde.org/kwin/db7fb26eedcac7effd908e34579cf2fa422ac22b