Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
1i5t5.duncan at cox.net
Mon Jan 23 19:21:17 GMT 2023
Frank Steinmetzger posted on Wed, 18 Jan 2023 14:15:08 +0100 as excerpted:
> In which other use case do we not want to auto-raise the window? If,
> say, we double-click an image in Dolphin and want it opened in gimp,
> which sits on another desktop.
> And this made me test it: I opened gimp on Desktop 1, Dolphin on Desktop
> 2, right-clicked an image and selected Open with… Gimp. And voilà: it
> showed the old behaviour: the gimp entry appeared on the taskbar and
> flashed. I clicked on it and was moved to Desktop 1.
> So the problem we have with firefox is either a firefox problem, or the
> setting “Switch to that desktop” didn’t work. And with “Bring window to
> current Virtual Desktop”, the Gimp window has moved Desktop, but was not
> raised to the top. So I suspect a Firefox problem here, not Kwin.
Reading that, seems to me the difference in behavior could be focus-
stealing related. I'd suggest:
1) Check that neither gimp nor firefox have a kwin window rule affecting
focus-stealing, and adjust/experiment with it if so.
2) Reexamine your general focus-stealing settings (under window behavior,
focus); perhaps testing strengthening them a notch or two and see if that
triggers other unwanted behavior.
3) If necessary (presumably because strengthening the general focus-
stealing prevention setting in #2 triggers other unwanted behavior),
experiment with a firefox anti-focus-stealing kwin window rule.
General notes on window rule focus rules:
There are two window rule settings affecting this, focus stealing
prevention, and focus protection, basically the inverse of stealing
prevention. Hover over them in the property-add dialog to get
descriptions. They interact with each other and the general setting based
on the window that has focus and the window that's attempting to get it,
so the extreme case for a single window would be setting one to extreme
while the other is set to none, but that would of course still interact
with the setting on the other window.
It is of course possible to set a fairly generic rule by adjusting the
window match wide enough, thus allowing the "other window" to have a
window rule matching it as well even when it could be any other app, but
keep in mind that in my experience, such general rules often require
possibly multiple specific exception rules as well, since they're
interfering with behavior as designed. (As an example, I have a general
window rule that forces most windows to my default activity, but had to
set exceptions for plasmashell windows to allow them to still appear on
the otherwise-blank non-default activity. Example 2, a rule that sets
active/inactive opacity, that requires exceptions for various windows
where that's inappropriate. Altho in this case that's not much more of a
bother since they really are exceptions that I want to treat differently,
so even without the generic rule I'd likely have exception rules for them
anyway.) Of course the overall result is a proliferation of window rules
due to generic rules, exceptions, and in some cases exceptions to
exceptions. But ultimately it works and I'm happy with it and that kde/
plasma makes such overrides possible in the first place. =:^)
And a caution:
Consider the possible security side-effects. As an example, consider a
browser password dialog (say for firefox's master password, if you have it
setup). Often you want it raised so you see it and can enter the
password, but the browser folks ultimately had to change their behavior a
bit because bad sites were trying to trigger popups without browser chrome
and setup to appear just like the default password dialogs, in ordered to
steal people's passwords. It's thus worth considering this case if
interfering with normal browser behavior, in case it might allow a popup
to mimic too closely the behavior of the password dialog. (OTOH, my
settings at least, tend to be customized enough that it'd pretty much take
someone who already had access to have enough information to properly
mimic behavior and fool me. A window that looks like a default Windows
dialog is going to stick out like a sore thumb! Unfortunately, based on
the number of people getting taken which must provide at least enough
reward for the bad guys to keep trying, many just blindly type and click
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde