Created attachment 183817 [details] Screenshot of window rule intended to place vncviewer on all desktops SUMMARY Window rule including force to all virtual desktops does not function; the window is only present on the desktop that happened to be active at the time. Other components of the rule (force to screen 1, run full screen, ignore global shortcuts) are honored. The use case is that I use my second display to run a VNC session to my work laptop. I want to be able to switch virtual desktops for my primary display while having the VNC session stay put. I can do it manually by taking vncviewer out of full screen mode, right clicking on the titlebar decoration, and selecting move to all desktops). OpenSUSE 15.6, kwin-x11 (wayland has some limitations that make it not feasible to use). STEPS TO REPRODUCE 1. Apply the window rule shown in the screenshot 2. Start vncviewer OBSERVED RESULT vncviewer only shows on the current desktop; if I switch desktops (I use alt-shift-left to switch to the next desktop on the left, for example), the vncviewer is not visible on that desktop. EXPECTED RESULT vncviewer should be present on all desktops SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: OpenSUSE 15.6 kernel 6.4.0 KDE Plasma Version: 6.4.3 KDE Frameworks Version: 5.116 or 6.16.0 (not sure just which) Qt Version: 6.9.1 ADDITIONAL INFORMATION
I'm not able to replicate this in git-master, or on Fedora 42 with Plasma 6.4.4, using similar rules for KRDC I couldn't reproduce with just the rule to force it on all Virtual desktops or with other rules added as well Can you reproduce this with a new user and just the rules for this one application? If you can, that rules out old cached or config values that might be interfering. Also, is this happening with other applications or just vncviewer?
I haven't tried with other apps. It's not easy for me to try with a different user (I have an enormous amount of state accumulated in my login). Note that this is also forced onto a secondary screen, and full screen, in case that affects anything. Where is the rule stored and what should it look like (the text)? vncviewer isn't a KDE app (it's from TigerVNC), in case that matters also. If I un-fullscreen it (so I see the titlebar), right click on the titlebar, select move to desktop->all desktops, it works going forward. But when I restart the VNC client it does not work.
Also, just in case it matters, I use focus follows mouse (mouse precedence), delay focus by 0 ms, focus stealing prevention high, neither box checked for raising windows, and separate screen focus.
There may be a typo in your window rules causing the problem. With the Window class substring match set to "vncviewer Vncviewer" (the default when I created them through the right click menu on the vncviewer window), the rules work. The window appears on all virtual desktops, on the screen I set, and is fullscreen In your screenshot I see the substring match set to "vncviewer vncviewer". With that, the window rules are not applied. Can you try changing the substring match and see if that makes the virtual desktop rule work? To answer the question about where the rules are stored they are in ~/.config/kwinrulesrc Here is what the entry for vncviewer looks like for me, with just the Virtual desktops, screen and fullscreen options set: [db55c999-890b-4a87-a1bf-3fca015fb20a] Description=Window settings for Vncviewer clientmachine=localhost desktops=\\0 desktopsrule=2 fullscreen=true fullscreenrule=2 screenrule=2 title=VNC Viewer: Connection Details types=1 wmclass=vncviewer Vncviewer wmclasscomplete=true wmclassmatch=2
That didn't help, which doesn't surprise me as the other parts of the rule (forcing to screen 1 and full screen) do work. This is my entry. I notice that yours doesn't have the 'screen=1' that mine does. You also have "match whole window class" set to Yes, which I didn't. With settting that to Yes, it did work. I still believe this to be a bug, as the other parts of the rule do work and someone might have a reason to need to do only a partial match. [1] Description=Window settings for vncviewer desktops=\\0 desktopsrule=2 disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=2 noborder=true noborderrule=2 screen=1 screenrule=2 wmclass=vncviewer Vncviewer wmclasscomplete=false wmclassmatch=2
Interestingly, I see that there's a second ruleset in my kwinrulesrc that I think I created once to test but deleted, and it doesn't show up in the UI. ``` [1] Description=Window settings for vncviewer desktops=\\0 desktopsrule=2 disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=2 noborder=true noborderrule=2 screen=1 screenrule=2 types=66463 wmclass=vncviewer Vncviewer wmclasscomplete=true wmclassmatch=2 [326c0f64-3ac4-47ca-b90e-df39c21cdcdf] Description=Copy of Window settings for vncviewer disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=2 noborder=true noborderrule=2 placement=4 placementrule=1 screen=1 screenrule=3 types=1 wmclass=vncviewer vncviewer wmclassmatch=2 ```
I did a little digging. I removed all rules for the vncviewer window, and used the right-click menu and UI to start over I started there by adding forcing on all virtual desktops, and changing to window class substring match Even with just that one rule, if i set "Match whole window class" to "no", the window rules are not applied (it only appears on one desktop) Removing the virtual desktop rule, and adding a rule to force fullscreen, that also does not work unless "Match whole window class" is true I had the same results when forcing to be on Screen 0 was the only rule So on my system, the virtual desktop rule is not the only rule where "Match whole window class" being false causes rules to not trigger Can you try removing all rules pertaining to vncviewer in kwinrulesrc, and then try the same test, with each rule and toggling "Match whole window class" between yes and no? This will rule out any conflicts from duplicate entries. Thanks.
Created attachment 184302 [details] kwinrulesrc kwinrulesrc triggers this if ``` wmclass=vncviewer Vncviewer wmclasscomplete=true ``` is changed to ``` wmclass=vncviewer ``` in the first rule set
It isn't entirely clear to me what you're asking. I have attached my kwinrulesrc so you can tell me more precisely what you'd like me to try here.
It's certainly possible that I just think that the fullscreen rule applies because I have vncviewer set to start up in fullscreen, so that part of the rule is gratuitous.
(In reply to rlk from comment #9) > It isn't entirely clear to me what you're asking. I have attached my > kwinrulesrc so you can tell me more precisely what you'd like me to try here. What I'd like is to start from a clean slate to make sure no old, stale or conflicting rules are in place. In that kwinrulesrc file, you have two sets of rules for vncviewer. This is likely contributing to the problem. Please remove this entire block and save the file: [1] Description=Window settings for vncviewer desktops=\\0 desktopsrule=2 disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=2 noborder=true noborderrule=2 screen=1 screenrule=2 types=66463 wmclass=vncviewer Vncviewer wmclasscomplete=true wmclassmatch=2 [326c0f64-3ac4-47ca-b90e-df39c21cdcdf] Description=Copy of Window settings for vncviewer disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=2 noborder=true noborderrule=2 placement=4 placementrule=1 screen=1 screenrule=3 types=1 wmclass=vncviewer vncviewer wmclassmatch=2 Then, open up vncviewer, right click on the title bar, and go to More Actions -> Special Window Settings Create the rules you want there. Let me know if that set of rules works. If not, please attach the new kwinrulesrc file. At this point, I suspect creating rules this way will get them to do what you want.
I've tried removing those entries, and while I can change other properties that take effect (e. g. no borders), nothing I can do now makes it come up on all desktops.
There is also no apparent way for me to restore the file to its original contents and get it to take effect.
OK, I've finally got it to work as follows: Description: Window settings for VNCviewer Window class (application) [Substring match] vncviewer Vncviewer Match whole window class: Yes Window types: [Everything but Dialog window] Virtual desktop [Force] [All desktops] Screen [Force] 1 Fullscreen [Apply initially] Yes Ignore global shortcuts [Force] Yes The kwinrulesrc stanza: [ad82ebe0-e1dc-408a-86ee-ca27aec7b141] Description=Window settings for Vncviewer desktops=\\0 desktopsrule=2 disableglobalshortcuts=true disableglobalshortcutsrule=2 fullscreen=true fullscreenrule=3 screen=1 screenrule=2 types=66463 wmclass=vncviewer Vncviewer wmclasscomplete=true wmclassmatch=2 It looks like if I now set window class back to exact match it's still working. I can't figure out just what's going on, unless there's some state in the window manager that's not being saved to the kwinrulesrc.
Thanks for the update. Now that the rules are working as you intended, is there still a bug here?
I'm not sure. When I created the rule from scratch I had problems. I suppose I can get rid of the rule and try again to create it from scratch with the settings to see that it's correct, or whether I have to fiddle around to get it right. But I can't do that right now.
(In reply to rlk from comment #16) > I'm not sure. When I created the rule from scratch I had problems. I > suppose I can get rid of the rule and try again to create it from scratch > with the settings to see that it's correct, or whether I have to fiddle > around to get it right. But I can't do that right now. If the rules work when creating them from the UI, but not from scratch with the exact same text,that would be a bug.
That isn't what I mean (although if I create rules by hand as text and put them in kwinrulesrc, they don't seem to actually take effect). What I mean is the sequence of operations I perform seems to matter, but I need to verify that.
> If the rules work when creating them from the UI, but not from scratch with the exact same text,that would be a bug. That would be kinda impossible technically :) In general I'd advise against touching the file manually except for debugging purposes (as is the case here), because there are some automatic things the UI does that need to be replicated: - To take place, the rule ID (the config group name) needs to be added to list in the `rules` property (in the `[General]` section) and will be processed in that order. - KWin needs to gets triggered to re-process the file when a rule changes, what the UI does. This can be done manually from the command line `qdbus org.kde.KWin /KWin org.kde.KWin.reconfigure`. Trying to follow up the sequence, I think there is not a bug here but a mismatched config file or more of an unexpected result? I'll try to explain what I got. Please, tell me if I missed/misunderstood something. The original rule would not work at all (any properties), because it wouldn't match. The `wmclass` property is quite weird because it means two different things depending on whether `wmclasscomplete` is selected. When that is `false` (or not in the file as it is the default) it needs just the first string of the "app" (just the first `vncviewer` in this case), so having two strings will make the match fail. This is a bit of an X11-ism, which we might improve in the future maybe. The second rule ID (`326c0f64-`) doesn't appear on the UI list, so what's written there will not affect the results and can be removed safely. I see a lot of other config groups and keys that shouldn't be there. I don't know what might have caused that, but should be harmless. I'd recommend to remove them in any case, those are the properties that end in [$d]