After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758706 - Add notification policy for system notifications
Add notification policy for system notifications
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: message-tray
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-11-26 13:50 UTC by Bastien Nocera
Modified: 2021-07-05 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2015-11-26 13:50:09 UTC
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

Instead of overloading "critical" to force showing certain notifications, it would be better to use a separate hint to guide OS notifications.

See bug 758521
Comment 1 Florian Müllner 2015-11-26 15:41:58 UTC
(In reply to Bastien Nocera from comment #0)
> Instead of overloading "critical" to force showing certain notifications, it
> would be better to use a separate hint to guide OS notifications.

What we do for critical notifications has some overlap with notification policy, but the two are not interchangeable - I do think a special policy for system notifications makes sense, but gsd should still provide an urgency to prioritize notifications.

In detail, policy covers the following settings:
 - enable               
   whether to show notifications (for this policy) at all; currently true for all
   OS notifications, I don't see a reason to change that

 - enableSound
   whether to allow notification sounds; OS notifications don't use those (thank 
   goddess!), so it doesn't really matter
   
 - showBanners
   whether to show the notification as popup (in addition to showing it in the
   calendar drop-down); currently follows the global 'show-banners' setting
   in org.gnome.desktop.notifications, which makes sense to me
   
 - forceExpanded
   whether to auto-expand long notifications; currently defaults to false, which
   looks right to me

 - showInLockScreen
   whether to show the notification on the screen shield; follows the global
   'show-in-lock-screen' setting, which again makes sense to me as well

 - detailsInLockScreen
   whether to show the actual message in the lock screen (or a generic summary);
   this is the one setting where I think OS notifications should differ from
   generic notifications and default to true (provided we are careful about not
   adding notifications that leak privacy-relevant information)
Comment 2 GNOME Infrastructure Team 2021-07-05 14:25:46 UTC
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.