SUMMARY The semantic of the Raise MPRIS method is not consistent. It changes with the state of the application: background or not. Raising an open window does not always bring it to foreground as should be. I think this should be fixed or at the very least be documented somewhere. RELATED COMPONENTS: Task Manager and Icons-Only Task Manager Widget, Media Player Widget STEPS TO REPRODUCE 1. Setup: - Install elisa (or any player that can play in background) - Write the provided script to file 2. Raise semantic 1: asks for attention and window does not appear - Minimise elisa - Raise elisa (systemtray>mediaplayer>rightclick>open OR use the provided script) - Elisa window change color in taskmanager but does not appear 3. Raise semantic 2: window appear - Make elisa play in the background (may need to be enabled in settings) - Raise elisa (systemtray>mediaplayer>rightclick>open OR use the provided script) - Elisa window appear in the foreground I also tested variations of this scheme with several plasma desktops and other players such as Firefox. Raise first script: ``` #!/bin/bash set -euo pipefail QDBUS=qdbus6 # Get first mpris enabled session FIRST_SESSION="$($QDBUS | grep '^ org.mpris' | head -n 1 | cut -d ' ' -f 2)" echo "Working on session: $FIRST_SESSION" CAN_RAISE="$($QDBUS $FIRST_SESSION /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.CanRaise)" echo "Session can raise: $CAN_RAISE" echo "Raising" $QDBUS $FIRST_SESSION /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Raise ``` OBSERVED RESULT If player is in background, its window appears on the current desktop, else if player window is open but not in focus then task-manager highlights the playing windows else player window is in focus and nothing happens. EXPECTED RESULT Minimized window/any window raised via MPRIS DBUS interface should be displayed in foreground and take focus. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250624 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.3-1-default (64-bit) Graphics Platform: Wayland
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.