| Summary: | Inconsistent handling of DBUS org.mpris.MediaPlayer2.Raise | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Rémi Piau <remi+kde> |
| Component: | Media Player widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | minor | CC: | kde, kde, nate, nicolas.fella |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Rémi Piau
2025-06-28 20:32:51 UTC
So basically, it fails to un-minimize the window if it's minimized? Raise is a request to the player to raise itself. What exactly happens then is up to the player, not Plasma. That said, because of a design deficiency in the MPRIS specification Raise cannot work as "expected" on Wayland. See https://gitlab.freedesktop.org/mpris/mpris-spec/-/issues/18 > So basically, it fails to un-minimize the window if it's minimized? This, at minimum, plus would be nice to get the player interface in focus. > Raise is a request to the player to raise itself. What exactly happens then is up to the player, not Plasma. I still believe raise semantics should make the player window take focus in anyway possible (as per https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html Raise "Brings the media player's user interface to the front using any appropriate mechanism available."). It was raising itself under X11 but compositor help may be needed under wayland. 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. The changing color of the task manager shows plasma is aware of the raise action (window requesting attention?), can it differentiate it from other type of attention request ? if so it should be able to act upon it. > That said, because of a design deficiency in the MPRIS specification Raise cannot work as "expected" on Wayland. See https://gitlab.freedesktop.org/mpris/mpris-spec/-/issues/18 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. Am I getting that right? I am not an expert on this topic please correct me if I'm making wrong assumptions. > 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 > 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 (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. |