When you just can't get a window rule to work...

[chconnor]

For more than 10 years (maybe 15?) I have struggled with this issue... most of the time the kwin window rules (Settings->Window Management->Window Rules) work great, and I use them to make applications open on certain screens, in certain positions, etc etc.

But now and then an application just can't be tamed. It's not a window matching problem, at least not at first glance: if I set the rule to "Force" it works fine, but I don't want it to be forced all the time. I want to use "Apply Initially". I would also settle for "Remember", but neither work.

I have tried in vain to figure out what might be going wrong. The latest problem app is VSCode (installed via .deb from here). My only guess is that the metadata kwin is using to "find" the window is not set by vscode as it starts up, e.g. maybe it doesn't set the window class of the window to the expected value until after kwin has checked it, or something to that effect. That's my only wild theory, anyway.

I tried various ways to see if I could catch the window in this hypothetical intermediate state (running wmctrl -l -x -p on a loop, or running xprop and clicking just as the app window opened, etc.) to no avail.

I've seen a lot of posts on the internet about this over the years and nobody seems to have an explanation or solution. Anything to be done here?

If memory serves, years ago there was a "Force for X seconds" type feature, which would also be a workaround, but if there once was, there is no longer. ("Force Temporarily" is not what it sounds like and is not appropriate in this case.)

Thanks for any ideas!

[oshunluvr]

Have you tried an Application rule instead of Window rule?

[chconnor]

Yes, same result, thanks.

Side question: is there a functional difference between window vs app rule if the options in the window rules GUI are the same?

[oshunluvr]

Weird that "Apply Initially" is the part not working.

I think the difference between "window" and "application" matching is how the window itself is detected. I has instances where one worked and the other didn't, which is why I commented.

I also generally use "Force" because I want a window in a specific spot.

[chconnor]

Thanks... after some investigation, I'm pretty sure they do the same thing, just with slightly different default options set for the window rule that pops up. The settings generated in .config/kwinrulesrc are identical once they are configured to be the same (and regardless, leaving the window role that the window rule has by default, or removing it, etc, doesn't help).

Window rule:

[5fd454bd-736e-4922-bae6-ac36329a5b13]
Description=code-via-window-rule
clientmachine=localhost
title=main.cpp - tstat (Workspace) - Visual Studio Code
wmclass=code
wmclassmatch=1​

App rule:

[fc0230aa-ecfe-4c85-ab09-040adaa670d7]
Description=code-via-app-settings
clientmachine=localhost
wmclass=code
wmclassmatch=1​

...the first one has "title" set but it's not in effect because "titlematch=" is not present, i.e. it just ignores the title in that case.

This is such a longstanding thing it makes me wonder if it's a bug, an unavoidable issue, or something I'm just not understanding. Maybe I should just report a bug somewhere... it just seems likely to me that however kwin determines who a window "initially" is is getting fooled by however this app starts itself up (and a bunch of other apps over the years that have confounded me...)