GNOME Bugzilla – Bug 686616
Don't show resident notifications on the lock screen
Last modified: 2021-07-05 14:25:27 UTC
This was something that I discussed with Jon, Cosimo and Marina recently. There are a few design questions that need answering. Right now, the lock screen displays resident notifications at the top, followed by a list of any transient updates that have occurred since the screen was locked. The primary use of resident notifications is to display ongoing media playback. Resident notifications (I hope I'm using the right terminology here) other than media don't really make sense in the lock screen though. An ongoing file transfer isn't interesting on the lock screen, for example - we can simply show the transient notification that the transfer has finished. The proposal here is to special case media playback in the lock screen, and not show other resident notifications. Another part of this issue is that it would be good if hard media keys worked in the shell. If you press the play button on your laptop or keyboard, the default music application should start, for example. Open design questions: * Should we always display the music section in the lock screen, even when music isn't being played? (I suspect not.) * Should the music special case only be used for the lock screen, or should it be used in the message tray also?
I am very much in favour of cleaning up the curtain notifications (and fix the horrible alignment for the messages that do belong here). I don't think showing music controls without actual playback makes sense on the lock screen (what should happen when you hit play?). While special casing media for the message tray might be worth investigating in the future, I think the generic behavior of the rhythmbox bubble we have is good enough for now).
I agree it makes sense to avoid resident notifications in the lock screen, especially if they were resident already before the lock happened - it could still make sense to still display resident notifications received after the screen is locked. I also think it's worth keeping the music player on the lock screen after playback has finished (so that you could start it again without unlocking), but it should go away as soon as no player is running anymore.
Special casing music (MPRIS support - I've been trying to contact eon to see if he can reuse his media player indicator code) is a separate bug
Just as a general comment: can we please stop adding more special cases in the shell? Not that I say it is bloated, but having more and more "features" in a single-threaded WM/compositor is not the best idea, IMHO. We can special case music while still having it as a resident notification, using the notification policy thing from bug 685926, and then we can even consider exposing that in the control-center. After, that's what I read as "Show details in the lock screen". So, no, I strongly object to implementing MPRIS in core shell, and I disagree with banning all non-music notifications from the screen lock.
(In reply to comment #4) > Just as a general comment: can we please stop adding more special cases in the > shell? Not that I say it is bloated, but having more and more "features" in a > single-threaded WM/compositor is not the best idea, IMHO. > We can special case music while still having it as a resident notification, > using the notification policy thing from bug 685926, and then we can even > consider exposing that in the control-center. After, that's what I read as > "Show details in the lock screen". > > So, no, I strongly object to implementing MPRIS in core shell, and I disagree > with banning all non-music notifications from the screen lock. IMHO MPRIS is just an implementation detail of how the application and the notification server talk with each other. Also this is not about banning all non-music notifications from the lock screen but about defining the behavior of *resident* notifications generally in the lock screen.
So, as an update: gsettings-desktop-schemas now includes the notification filtering settings, and among those there is resident-in-lock-screen, which is meant to force notifications to behave "like rhythmbox". Now, I'm not particularly sure of the best way forward, but I see three options: - Keep the existing (in bug 685926) behavior of "notification is resident OR resident-in-lock-screen is true" - Ignore the resident flag on notifications and look only at the resident-in-lock-screen setting. This would need some other special case for Rhythmbox, for example a category hint. - Remove code that deals with resident notifications in the lock screen (dirty code), implement music with MPRIS. This leaves dangling the "Show details in the lock screen" switch from the control center mockups.
Updating the update: since 8cb3884fae67a20a2b87f442479cfdb5feb8a9c8 (Jan 30th), we no longer show resident notifications in full in the lock screen. If the user opted in for details, we show the list of notifications as "Summary: banner", otherwise we just show the number. Music notifications (with the category 'x-gnome.music') are special cased and are shown first. It would be possible to apply a different layout, to more closely match the mockups, but I don't think we need to implement MPRIS. Which means... is there anything left here?
(In reply to comment #7) > Which means... is there anything left here? I guess not. Let's use bug 702305 for the relayout of music on the lock screen.
I'm reopening this - I don't think it is resolved. There are a few issues here: * All notifications should be of equal size - otherwise it messes up the visual appearance. * I can't think of a case other than music where you would want to treat lock screen notifications differently. * The current music notification on the lock screen looks terrible. Mockups for how the music notification should look can be found here: https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock/310Redesign
Another issue: * Rhythmbox currently remains on the lock screen when nothing is playing. It says "Not playing". :(
Created attachment 253761 [details] [review] ScreenShield: use a more compact layout for music notifications Use a smaller image and move the labels and the buttons on the side of it. Also hide the application icon.
Created attachment 253763 [details] before
Created attachment 253764 [details] after
Note: the text comes from gnome-music / rhythmbox, if we want to remove the album name we need to patch there.
No success in attracting any ui review of this :-( Moving off 3.10 blocker list
The patch seems like a definite improvement to me, although I'd like to see a screenshot of it in action with other notifications present. I also think that we should try and remove the album name, but I don't think that's a blocker.
(In reply to comment #16) > I also think that we should try and remove the album name, but I don't think > that's a blocker. Would you remove it just from the lock screen, or from all music notifications?
(In reply to comment #17) > (In reply to comment #16) > > I also think that we should try and remove the album name, but I don't think > > that's a blocker. > > Would you remove it just from the lock screen, or from all music notifications? All music notifications, probably. Three pieces of information just seems like overkill.
Comment on attachment 253761 [details] [review] ScreenShield: use a more compact layout for music notifications Doesn't apply cleanly anymore.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.