Notifications are closed automatically with reason expired about notifications HOT 5 CLOSED

I think this might be a case where the spec was written before OSes persisted notifications in an indicator. It looks like GNOME does not close the notification with reason 1 when it goes off screen; the notification remains open until a user dismisses it, and there's no distinction between closing it from on-screen and closing it from the indicator.

We think GNOME uses expiration to decide when the notification should be closed (no longer visible anywhere, removed from the indicator, no longer actionable), not how long it should remain on the screen. Which, tbh I don't think I'd want apps being able to manually tell the OS how long to keep their notification on screen anyway, that's basically what priority is for, but I can see it being useful to tell the server "this notification is only good for x time" and have it automatically dismiss the notification completely after that time.

from notifications.

It looks like GNOME expires notifications in two cases: when they've hit a max notifications per source, or when the notification is set to transient. But not when they're moved from the screen to the indicator.

from notifications.

After discussion in Slack, it sounds like the minimally-invasive steps forward would be:

1. Don't expire notifications when they move from the screen to the indicator
2. Ignore application-provided expiration since apps shouldn't be determining how long we show them to users (that's what priority is for)

There are some larger issues around the spec, but it sounds like this should still comply with the spec and be more similar to GNOME Shell's implementation.

from notifications.

I understand from @djordan2 that this is a big issue when trying to use System76's system76-hidpi-daemon.
Also see: https://www.reddit.com/r/elementaryos/comments/7c7x8x/pop_os_mixeddpi_multimonitor_setup_on_elementaryos/

from notifications.

@peteruithoven it is indeed exposed by the HiDPI daemon. However, I would probably categorize the daemon as a series of (admittedly impressive) hacks that happens to work in GNOME Shell because of a different interpretation of a spec. 😉

Using notifications for HiDPI feels like a bit if a crutch; I'd much rather see a daemon that runs and handles the display settings and can be communicated with over DBus. This is how many other freedesktop and GNOME components work and achieve cross-DE usability. If that were the case, one could write a simple system indicator for elementary OS that handled it in a more standardized way (and one could even include settings in the Displays plug).

Until then, yes, the current notification behavior is problematic.

from notifications.