GNOME Bugzilla – Bug 758521
mysterious "Power: 1 new notification"
Last modified: 2015-11-26 14:56:02 UTC
Created attachment 316074 [details] screenshot Whenever my laptop's been idle for a few minutes, the screen lights up and the screenshield shows up with a "Power: 1 new notification" pseudo-notification. If I as much as move the mouse cursor, the notification disappears. Investigating with dbus-monitor, this seems to be the "Automatic suspend" notification ("Computer will suspend very soon because of inactivity."). At minimum, I'd like to *make the notification's full contents visible in the screenshield*, so that I at least know what's it about. But since the notifications are sent without a desktop-file, I can't do that – there's no matching program entry in Settings›Notifications. Alternatively, maybe that's not even worth waking up the screen for? --- method call time=1448259653.141583 sender=:1.10 -> destination=:1.15 serial=290 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify string "Power" uint32 0 string "" string "Automatic suspend" string "Computer will suspend very soon because of inactivity." array [ ] array [ dict entry( string "urgency" variant byte 2 ) ] int32 0 --- gnome-settings-daemon 3.16.x, 3.18.x
(In reply to Mantas Mikulėnas from comment #0) > Created attachment 316074 [details] > screenshot > > Whenever my laptop's been idle for a few minutes, the screen lights up and > the screenshield shows up with a "Power: 1 new notification" > pseudo-notification. If I as much as move the mouse cursor, the notification > disappears. Why pseudo-notification? Because it's not complete? Well, given the content of the notification below, it's expected to disappear if you move the mouse. > Investigating with dbus-monitor, this seems to be the "Automatic suspend" > notification ("Computer will suspend very soon because of inactivity."). > > At minimum, I'd like to *make the notification's full contents visible in > the screenshield*, so that I at least know what's it about. But since the > notifications are sent without a desktop-file, I can't do that – there's no > matching program entry in Settings›Notifications. Easier said than done. The only .desktop file we could latch onto is the Power panel, which I really don't want to appear separately in the Notifications panel. Instead, we should find a way for it not to appear in the Notifications panel, and make gnome-shell always show the notification expanded. > Alternatively, maybe that's not even worth waking up the screen for? It certainly is. See bug 597030.
Shell hackers, any hint on how to do this? I think we might need a special case for gnome-settings-daemon (which is special, in any case...).
(In reply to Bastien Nocera from comment #1) > (In reply to Mantas Mikulėnas from comment #0) > > Created attachment 316074 [details] > > screenshot > > > > Whenever my laptop's been idle for a few minutes, the screen lights up and > > the screenshield shows up with a "Power: 1 new notification" > > pseudo-notification. If I as much as move the mouse cursor, the notification > > disappears. > > Why pseudo-notification? Because it's not complete? Yeah – well, what I had in mind was "collapsed notification" or something such? > Well, given the content > of the notification below, it's expected to disappear if you move the mouse. That's alright, but always showing the content would make that clearer – it took me a while to figure out. > > Investigating with dbus-monitor, this seems to be the "Automatic suspend" > > notification ("Computer will suspend very soon because of inactivity."). > > > > At minimum, I'd like to *make the notification's full contents visible in > > the screenshield*, so that I at least know what's it about. But since the > > notifications are sent without a desktop-file, I can't do that – there's no > > matching program entry in Settings›Notifications. > > Easier said than done. The only .desktop file we could latch onto is the > Power panel, which I really don't want to appear separately in the > Notifications panel. I see... I wonder if it's similar to certain Android notifications coming from an app named "System UI"? > > Alternatively, maybe that's not even worth waking up the screen for? > > It certainly is. See bug 597030. Fair enough.
Created attachment 316190 [details] [review] power: Always expand power notifications Work-around weird notification semantics where power related notifications wouldn't be expanded in the lock screen.
I really don't like doing this, but it's as good as I can do if we don't make changes to gnome-shell, or hard-code some policy in gnome-shell for gnome-settings-daemon (which is part of the OS after all).
Attachment 316190 [details] pushed as e0edc15 - power: Always expand power notifications
(In reply to Bastien Nocera from comment #5) > I really don't like doing this Yeah, me neither - critical notifications don't just auto-expand, they also jump to the head of the queue and don't time out (i.e. block all normal notifications until dismissed by the user). > make changes to gnome-shell, or hard-code some policy in gnome-shell for > gnome-settings-daemon (which is part of the OS after all). We already have different notification policies (depending on whether we can find a matching .desktop file or not), so adding another one for system notifications sounds fine, provided that we can come up with a policy that makes sense for all system notifications of course. The part where I'm still undecided is how to best determine which notifications are system notifications. Some custom 'x-gnome.system' hint would be easiest, but also ugly; getting the well-known name that corresponds to a unique sender name is cumbersome; matching a PID to an exectuable is unreliable and OS-specific; matching the notification sender PID to "system PIDs" means we need to monitor 'org.gnome.SettingsDaemon' (and possibly other components?) ... I lean towards the last option, unless you have objections and/or a better suggestion.
(In reply to Florian Müllner from comment #7) > (In reply to Bastien Nocera from comment #5) > > I really don't like doing this > > Yeah, me neither - critical notifications don't just auto-expand, they also > jump to the head of the queue and don't time out (i.e. block all normal > notifications until dismissed by the user). Is it appropriate for "low battery" notifications? It probably is. > > make changes to gnome-shell, or hard-code some policy in gnome-shell for > > gnome-settings-daemon (which is part of the OS after all). > > We already have different notification policies (depending on whether we can > find a matching .desktop file or not), so adding another one for system > notifications sounds fine, provided that we can come up with a policy that > makes sense for all system notifications of course. > > The part where I'm still undecided is how to best determine which > notifications are system notifications. Some custom 'x-gnome.system' hint > would be easiest, but also ugly; getting the well-known name that > corresponds to a unique sender name is cumbersome; matching a PID to an > exectuable is unreliable and OS-specific; matching the notification sender > PID to "system PIDs" means we need to monitor 'org.gnome.SettingsDaemon' > (and possibly other components?) ... > I lean towards the last option, unless you have objections and/or a better > suggestion. In gnome-settings-daemon, we have notifications for: - Slow keys, sticky keys being turned on, "critical" behaviour sounds fine - Color recalibration needed, uses "low" urgency - Timezone updated, uses "normal" urgency - Low disk space, uses "critical" but probably shouldn't - Low battery, uses "critical" - Printers shows notifications when connecting to devices and printing, or installing drivers, uses default urgency - When wacom devices aren't recognised, with normal urgency We might looking at splitting gnome-settings-daemon into separate smaller daemons, so monitoring a single D-Bus name won't work, and some of them won't be on the bus with a well-known name. Using an "x-gnome.system" hint to influence the behaviour seems the easiest to me, but we'll need to review our uses of notifications. I've filed bug 758706 about this.
(In reply to Bastien Nocera from comment #8) > > Yeah, me neither - critical notifications don't just auto-expand, they also > > jump to the head of the queue and don't time out (i.e. block all normal > > notifications until dismissed by the user). > > Is it appropriate for "low battery" notifications? It probably is. It's the prime example of a critical notification IMHO, so yes - if the users ignores the notification, we suspend or shutdown, which is about as disruptive as it gets. > We might looking at splitting gnome-settings-daemon into separate smaller > daemons, so monitoring a single D-Bus name won't work, and some of them > won't be on the bus with a well-known name. Ah, I was aware of the plan to split gsd, but not that the components might not have a well-known name. Let's scrap this then ... > Using an "x-gnome.system" hint to influence the behaviour seems the easiest > to me It's also easy to use for app developers who want to work around the notification settings, but that's not something I can't live with - so let's go with that. > I've filed bug 758706 about this. Yeah, let's move this there.