https://bugs.kde.org/show_bug.cgi?id=429171
--- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #5) > (In reply to Thiago Sueto from comment #3) > > 2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot > > reproduce > Definitely more testing required for X/gtk2/etc to see what the difference > is here. OK, tried generic X (xeyes, xev) and gtk2/X (claws, gimv/gimageviewer, pan, xscreensaver-demo), and everything X-based I tried seemed to "just work" with the no-titlebar-and-frame rule clause, including vlc with its qt5 interface which despite being qt5 is still X (wmctrl, an X-based window-manager scripting tool, still lists vlc, while it doesn't list native-wayland windows). If it's not for you, it may be the difference between my live-git build (as of two days ago now) and your AFAIK release-version tumbleweed and neon (to a lessor extent if you're trying neon unstable?). It's the native wayland stuff that kwin is failing to properly assert the no-titlebar-and-frame clause on, and that's the case whether it's gtk3/python3.8/wayland (solaar), qt5/python3.8/wayland (hplip's device-manager), gtk3/wayland (firefox), or kde5/plasma5/qt5/wayland (konsole, kpat and ksudoku most thoroughly tested here). Tho firefox and hplip's device manager, plus konsole, kpat and ksudoku, tend to title-change, triggering the settings that way, while solaar doesn't. So the bug must be in kwin's handling of the wayland protocol, since it affects all wayland-based windows I've thrown at it be they qt5 or gtk3 based, while it does /not/ affect the qt5 but still X vlc or any other X-based windows I've thrown at it. Which is interesting since kwin, unlike some of the other wayland compositors, does server-side (aka compositor-side) decorations, so it *has* to know the titlebar parameters and be in control over whether the titlebar and frames appear since it draws them! I still believe it's some sort of race between the titlebar/frame drawing code and the window detection, now known to be limited to the wayland-native code path, since the other rule clauses generally apply fine, and the titlebar/frame clause does too, if a title change comes in (and apparently now if a title set comes in even if it just sets the same title as it had before, see comment #6). Well, with that recent improvement being two days old now, I need to do another update and see if there's further improvements. Maybe I'll get lucky and be able to say it's fixed. There's another bug of mine, bug #429588 (that one window-rules kcm but not wayland-related), resolved/fixed that I've not yet picked up, too. Actually, Nate Graham, who resolved the bug, said that one was fixed right about as I was filing it.=:^) -- You are receiving this mail because: You are watching all bug changes.
