[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Roke Julian Lockhart Beedell <4wy78...@rokejulianlockhart.addy.io> changed: What|Removed |Added CC||4wy78uwh@rokejulianlockhart ||.addy.io --- Comment #11 from Roke Julian Lockhart Beedell <4wy78...@rokejulianlockhart.addy.io> --- (In reply to Duncan from comment #1) > So it appears no-titlebar rules are broken on new wayland windows regardless > of whether the windows are qt/kde or gtk basis, while X windows appear to > work fine. 1i5t5.dun...@cox.net, I haven't seen this mentioned here, so https://bugs.kde.org/show_bug.cgi?id=452240 might be what you're looking for. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Ismael Asensio changed: What|Removed |Added Version Fixed In||5.22.90 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/plas ||ma/kwin/commit/bb0f749ee7d1 ||589048eebe1620f53978bbf4681 ||e --- Comment #10 from Ismael Asensio --- Git commit bb0f749ee7d1589048eebe1620f53978bbf4681e by Ismael Asensio. Committed on 04/09/2021 at 10:47. Pushed by meven into branch 'master'. xdgshellclient: Fix "noBorder" rule on initialization The check for this rule was missing on window initialization, so on Wayland it wasn't being applied until something would trigger the check again. FIXED-IN: 5.22.90 M +1-0src/xdgshellclient.cpp https://invent.kde.org/plasma/kwin/commit/bb0f749ee7d1589048eebe1620f53978bbf4681e -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Nate Graham changed: What|Removed |Added CC||n...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Bug Janitor Service changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 --- Comment #9 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1373 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Ismael Asensio changed: What|Removed |Added CC||ky...@iki.fi --- Comment #8 from Ismael Asensio --- *** Bug 436854 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
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.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 --- Comment #6 from Duncan <1i5t5.dun...@cox.net> --- After yesterday's update, things improved incrementally. I'm not sure what exactly triggered the improvement, but... kwin seems to notice changes in windows and reapply its rules more often now, often triggering no-titlebar if it's set, when it wouldn't before. My /theory/ is that it's noticing when window titles are set, even if they don't actually change from whatever they were set to before, now, whereas before, it would only notice changes if the window title actually changed, not if it was set to the same value it had before. Noticed in kpat and ksudoku, which start with a titlebar now despite a window rule turning it off for them, but which switch to no-titlebar mode, for instance when I start a game. While that happened before if the window title changed, now two reevaluations seem to be triggered, the first of which turns off the titlebar but doesn't reset the window size resulting in a shorter window than the set size because it's accounting for the titlebar which isn't there now, the second of which resets the size to that set by the rule as well. Before, it was only one triggered reevaluation. I can _guess_ that the one trigger sets the title to the same value it had before so it didn't trigger before, leaving on the trigger that actually changed the title, while now they both trigger. But of course since the title doesn't change with the one trigger, it's difficult to /prove/ that, leaving me /guessing/ as to the reasons for the now observed second observed trigger. And while I did read the git log for kwin and some of the updated frameworks (as I routinely do), no single commit log leapt out at me as the reason for the improvement. But it's nice to have, regardless. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Flags||Wayland+, X11- --- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- Adding flags +wayland -X11, plus this reply... (In reply to Thiago Sueto from comment #3) > I can partially reproduce: > > 1) Window rules are not remembered after closing <-- 100% reproducible with > Qt/KDE and GTK3 apps Thanks. > 2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot > reproduce Hmm. I wonder if it's working here for claws due to the title update thing? Do you have a mail account setup in it? Presumably it starts with a generic title and updates it to include the default email account. That could trigger the title update... The other thing... your claws is still gtk2/X-based, coming up on wayland via xwayland, right? Mine is. Last I looked into it the claws folks were working on gtk3 and presumably native wayland support with it, but that was probably 6 months or a year ago. I've not looked at it since, and definitely not since switching to kde/plasma-wayland. But if they've updated and the openSUSE tumbleweed build is gtk3/native-wayland that might explain the difference. Definitely more testing required for X/gtk2/etc to see what the difference is here. I just tried xev, being the one X-based app I could think of off the top of my head, and couldn't get the titlebar to force off for it, but it's "strange" in that the window-rules detection couldn't find a window-class for it, and of course it doesn't appear to change window title so I can't test that part of it. I'll have to try some others... > 3) If includes title, rule works after updating title <-- Cannot reproduce Hmm. That's pretty solid here. In fact, for one thing I run here, a text-based pdmenu in a konsole window, FWIW, due to this bug I'm actually having to deliberately script a title change via konsole/xterm escape sequences in ordered to trigger the detection and turn off the titlebar.[1] But if my theory above that my seeing claws obey no-titlebar rules, possible because of a title change I wasn't aware was happening, is correct, then if a title change isn't triggering no-titlebar rule enforcement for you, it would explain that too. Meanwhile, another development, but I'll put that in a different comment. --- [1] pdmenu was designed as a text-based menu and pops up in the middle of the terminal. It has customizable colors, and between them, setting konsole command-line switches for no toolbars/tabbars/scrollbars, and using a custom konsole color-scheme with a 100% transparent background (the menu itself has a background color set so it's not transparent, but the rather bigger konsole window it's appearing in is), I can make it appear as if the relatively small text-based menu is popping up by itself, not in the much bigger konsole/terminal window it's actually in -- as long as the titlebar doesn't appear to destroy the illusion. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 --- Comment #4 from Thiago Sueto --- I tested this on KDE Neon Unstable as well, I experienced the same behavior as comment 3. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 Thiago Sueto changed: What|Removed |Added CC||herzensch...@gmail.com --- Comment #3 from Thiago Sueto --- I can partially reproduce: 1) Window rules are not remembered after closing <-- 100% reproducible with Qt/KDE and GTK3 apps 2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot reproduce 3) If includes title, rule works after updating title <-- Cannot reproduce Operating System: openSUSE Tumbleweed 20201119 KDE Plasma Version: 5.20.80 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.1 Kernel Version: 5.9.8-2-default -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Addendum: I just discovered that if the match includes title and it's set to substring, while the initial window won't trigger the rule (even if it's a match), but when the title changes (from a substring that matches and should trigger but hasn't, to a different substring that matches), the rule will then be triggered. If the rule includes both size and no-titlebar clauses, at the title-change trigger the no-titlebar part will trigger but that won't trigger a re-application of the size rule, so then the size is no longer what's set, despite it being in the same rule. However, if the title changes again, triggering another re-match, since the no-titlebar is already applied, on the second rematch the size will again be forced to the set size. So the rules are getting applied, but only on /change/, in this case, when the title changes, triggering a new match on title substring. Maybe the title match on substring condition is tested /after/ the no-titlebar clause is applied, so at first the no-titlebar clause isn't applied because the match hasn't been fully tested yet? I believe that would create this behavior as only the title substring change would then trigger the match. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429171] wayland: window rules, no titlebar and frame, won't auto-apply
https://bugs.kde.org/show_bug.cgi?id=429171 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- FWIW tried firefox now too (couldn't shut it down before submitting the initial report), AFAIK the only non-kde thing I have that does a true wayland window, and same broken behavior. So it appears no-titlebar rules are broken on new wayland windows regardless of whether the windows are qt/kde or gtk basis, while X windows appear to work fine. -- You are receiving this mail because: You are watching all bug changes.
