Bug 497857 - Window Rules no longer works: right click menubar → Configure special window settings no longer creates an empty rule with the current window's info filled in, and detect window properties button does nothing
Summary: Window Rules no longer works: right click menubar → Configure special window ...
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.2.4
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-24 10:10 UTC by triffid.hunter
Modified: 2025-01-02 16:06 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description triffid.hunter 2024-12-24 10:10:11 UTC 
SUMMARY

Window Rules no longer works properly: right click menubar → Configure special window settings just brings up a list of window rules instead of creating an empty rule with the current window's info filled in, and detect window properties button does nothing.

STEPS TO REPRODUCE
1. right click menu bar → more actions → Configure special window (or application) settings
2. While editing a window rule, click 'Detect window properties', click on a window

OBSERVED RESULT

Instead of making a new rule for the selected window, a list of existing window rules pops up.

If I manually create a new rule, the 'Detect window properties' button does nothing - no effect when clicked at all, and if I click another window it just focuses that window but doesn't fill in any properties.

EXPECTED RESULT

1. As per previous versions of kwin, right click menu bar → more actions → Configure special window (or application) settings should create a new window rule with the selected window's properties already filled in, and allow me to add or remove overrides.

2. As per previous versions of kwin, clicking 'Detect window properties' should change the cursor to a crosshair, and upon click, fill the Window Rule properties with the details of the clicked window

SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 2.17
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.3
Kernel Version: 6.12.5-dorellan (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION

This worked fine in kwin-6.1.5, and it's a feature I use fairly frequently

I guess whatever it uses to detect window properties fails, so it just falls back to showing a list of rules or having the 'Detect…' button do nothing.

I'm not sure which specific component this fits under, so I chose 'generic' - and I'm only somewhat sure this is a kwin issue since I'm not sure which KDE component handles the 'Configure special window settings' menu bar action
Comment 1 John Kizer 2025-01-02 06:52:50 UTC 
Hi - I can't reproduce this on my system below, so I wanted to ask:

* Does the same behavior occur in a Wayland session?
* Not sure if this would be related, but does the same behavior occur if Frameworks and Qt are upgraded? Just a thought if there's something funky going on because the Plasma version is extremely up-to-date, yet Frameworks is a couple of versions older.

Thanks!

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.6-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7800X3D 8-Core Processor
Memory: 30.4 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2
Comment 2 triffid.hunter 2025-01-02 09:46:14 UTC 
I haven't managed to get Wayland working, so can't test that.

As for frameworks, 6.7.0 seems to be the latest stable on Gentoo (see KEYWORDS in https://github.com/gentoo/gentoo/tree/master/kde-frameworks/ various ebuilds)  - with the only other option being 6.9.0 marked as testing/unstable (KEYWORDS="~amd64 …").
Conversely (over in https://github.com/gentoo/gentoo/tree/master/kde-plasma/ various) plasma 6.2.4 is stable while 6.2.5 is testing/unstable.
Also, Qt (https://github.com/gentoo/gentoo/tree/master/dev-qt/ various ) 6.8.1 has been stabilized since I posted this bug.

If you think there's some specific issue with Gentoo KDE team's stabilization choices, drop some details and I can make a downstream bug.

Curiously, this issue seems to have disappeared after a couple of reboots - so perhaps we can close for now and I'll reopen if I find a way to make it reappear?
Comment 3 John Kizer 2025-01-02 16:06:01 UTC 
(In reply to triffid.hunter from comment #2)
> If you think there's some specific issue with Gentoo KDE team's
> stabilization choices, drop some details and I can make a downstream bug.

I definitely don't know if that's an issue, it just stuck out to me as a surprising combination of very recent and slightly less-recent components that, for that reason, might not have ever been tested together? 
 
> Curiously, this issue seems to have disappeared after a couple of reboots -
> so perhaps we can close for now and I'll reopen if I find a way to make it
> reappear?

Yep, especially if there's anything that can be noted about any circumstances that changed around the time it pops back up, if it does - ex. time since a certain event, presence of specific windows, session status, display settings, anything like that which might provide a clue :-)