Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?

[René J.V. Bertin]

On Friday December 16 2022 04:20:50 Duncan wrote:

Thanks,

but

>be the default (or only available behavior as it was before) because it 
>/is/ confusing.

Sorry, your entire answer is a little confusion to read through. 

>Old and definitely confusing but arguably could-be-useful behavior, now 
>missing option:

Can you tell what version of KWin introduced the setting and in what version range the option is/was present? I'm using KWin 5.12.x (probably ancient but it does the trick for me just fine) and I cannot seem to find the entire setting in the "Window Behaviour" KCM.

And, supposing my KWin version only has that "old and [...] arguably could-be-useful behaviour", how come FF manages to get the window to the current desktop - is there a specific call that can be made just to change the desktop a window is displayed on? (AFAIK virtual desktops are not an X11 concept!)

>
>* Only switch to that desktop if manually activating a window, via alt-
>tab, taskbar, etc.  If an existing window on a different virtual desktop 
...
>Of course besides being confusing it's just harder to clearly explain in a 
>short form similar to the above choices, and it'd certainly be the most 
>esoteric choice, so I can't really blame them for losing it, but it's 
>still lost behavior that some people might miss...

What's confusing about it? It just means "don't change desktops unless the user really wants it". Or, call the option "don't change desktops" and leave it to change the desktop via one of the actions designated for that particular purpose. It'd be debatable in that case whether clicking on a window representation in the panel could be included *)

In theory it sounds fine to switch to the target desktop, but in practice that can be just as annoying as having to switch manually. How often does it happen that you read through an email with a list of some kind of offers and you just want to process that list first, opening the links as a stack that remains in the background? KDE was always great for power users with methods like that ... losing them really feels like laziness on the part of the devs carrying on the torch...

R.


*) Or not be debatable, once you realise that that too is an action that could well have multiple effects. Already the effect depends on whether or not the widget represents what resumes to a single window or an application with multiple windows open.

PS: for anyone wondering about the same FF thing, there may be a workaround in https://bugzilla.mozilla.org/show_bug.cgi?id=1805766 . It works for me, and now I have to dig out the window myself, but that turns out to be much less invasive/production-inhibiting than I thought.