https://bugs.kde.org/show_bug.cgi?id=506324
Rémi Piau <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |RESOLVED Resolution|--- |NOT A BUG --- Comment #5 from Rémi Piau <[email protected]> --- (In reply to Nicolas Fella from comment #4) > > Moreover, i think edge cases may need plasma help to function properly, for > > example: when raising a player running in another virtual desktop, raise > > should either: > > - switch to the VD containing the player window virtual and put the player > > window in the foreground > > - or bring the player window into the current VD and put the player window > > in the foreground. > > That will work automatically if the window properly activates itself Do that mean that they should implement xdg-activation ( https://wayland.app/protocols/xdg-activation-v1 ) ? If the fix for a working and consistent semantic for any app is to properly implement raise, we should probably document how to do so somewhere. Best case we include a link to an app implementing that properly under wayland as it seems non trival. > > > I think this is needed for the application to raise itself up (make raise > > work in exactly the same application controlled way in every Wayland > > compositor) but from my reading of the raise method it is not mandatory > > that the application raise itself and most/all of them don't, plasma could > > detect the dbus signal and take appropriate step to put the player window > > in focus. > > Raise doesn't necessarily make sense for every player, imaging a background > daemon without any windows. Also, in order to do what you are describing > Plasma would need to "guess" which window(s) belong to a player and which > one should be raised. Not very reliable so I'd rather not do that Thanks for this explanation. I believe I understand the way it should work. This can thus be closed. -- You are receiving this mail because: You are watching all bug changes.
