Future features for Notification interface

[jsparber]

A lot of features proposed in #983 landed now in version 2. Some features didn't make the cut. This tries to collect additional features we discussed already while creating v2. Some of them would be nice to have in near future for v3.

• Threading
  Group notifications from the same app into a thread, eg. for multiple chat messages from one contact

• Vibration
  Allow an app to set a vibration pattern played when the notification is shown. This can be based on the Web Vibration API specification which is similar to android's API

• Notification Led
  Allow apps to specify a led color that will be used on devices that have a notification led. Android has an API for it.

• Progress indicator
  Show a progress bar in notifications e.g for file copy

• Image preview
  Large image for the body of the notification, including alt text for accessibility

• Alternative notification
  Allow apps to specify an alternative notification for the lockscreen

• Timeout
  Allow apps to specify I timeout of timestamp when the event ends, useful for things like calendar appointments

• desktop-file-id
  Application settable desktop file id.
  Partially solved with notification: Add the desktop-file-id key for portal backends #1488

• Permission requests
  Ask the user whether they want to receive notifications from this app. Ideally, apps should ask for permission before sending a notification, since the permission dialog shouldn't popup at random but when the user expects it.

Feel free to comment if I missed features we discussed already and didn't land with v2.

[Mikenux]

I changed my mind about the permission to send notifications, but I take that as a "reason" to run in the background.

[Mikenux]

I opened a discussion: #1496.

Note that the second user experience (when the app is closed) is to let the app send in-app notifications. For example, this is (or was?) the case of Dolphin, the KDE file manager, which displays the progress of file operations.

[DemiMarie]

What about:

• Persistent notifications that persist after the app closes.
• Feature parity with macOS and Windows.

[jsparber]

Persistent notifications that persist after the app closes.

Already the case, if the notification server implements it and the app uses D-Bus Activation.

Feature parity with macOS and Windows.

Would love that, but not relevant for xdg portals since they aren't used on Mac and Windows

The above list wasn't intended to be an exhaustive list, but more a collection of features that were discussed already at some point.

[DemiMarie]

Persistent notifications that persist after the app closes.

Already the case, if the notification server implements it and the app uses D-Bus Activation.

That is great! I thought this was not supported, but I am glad to be wrong. Is there some sort of ID that can be used to identify the notification, or should the app just include that itself?

Feature parity with macOS and Windows.

Would love that, but not relevant for xdg portals since they aren't used on Mac and Windows

I meant “feature parity with macOS and Windows notification APIs”, meaning that notifications are as featureful on Linux as they are on proprietary desktop OSs in the absence of a good reason (such as security) for them not to be.

[Levi-Lesches]

Hi @jsparber @jonas2515, I was reading through the v2 proposal and saw this:

Things we don't want

• We don't want API for showing "n unseen notifications" badges on app icons.

I didn't see this discussed anywhere in that thread -- but why not? Badges are supported on every other platform: Windows, MacOS, iOS, Android, and even Web. Googling "Linux app badges" shows bug reports (mostly about Discord) from users concerned that they can't see their badges, so I'd argue it's a feature people want. Is this already implemented/described elsewhere, or is this really not planned?

[orowith2os]

Oh, never mind, I see what you're talking about. Yeah, that makes sense. Just passing a number for unread messages would make sense, I think. Any more information on this?

[Mikenux]

I think a dedicated discussion should be open about this.

[Levi-Lesches]

This thread seems general enough, as it talks about future features in general.

@jsparber, if you think it's appropriate, I can open a new thread for this.

[Mikenux]

Note: This could perhaps work as a category of new notifications. This means that an "unread" badge will be limited to new unread messages, not those that exist before an app is installed.

[Levi-Lesches]

@Mikenux given it's been two months and there is other activity on the repo, I've opened a new discussion at #1617

[12people]

I'd love to see:

• Scheduled notifications
• Repeat notifications

(Both of those are available on Android, iOS, and macOS.)

I started a separate conversation on this topic: #1696

[Mikenux]

Badges: #1702. Having something specific for badges wasn't avoidable. However, this does not prevent a server from not supporting them.

[Mikenux]

Awareness of Do Not Disturb: #1321

[jadahl]

Progress indicator
Show a progress bar in notifications e.g for file copy

I wonder if this could be morphed into the use case of showing progress bars on dash/dock app icons without an actual notification bubble, or if that should be handled separately.

[Play-InTheWay]

I'm now wondering about visually distinguishing failed progress from successful finished progress

Normally it is done through coloring the progress bar with a specific set of colors, mainly being

• Green: in progress
• Yellow: Paused
• Red: Error/Stopped

The themes question shouldn't be an issue here, because as far as I know, they also have specified colors for similar things in the interface with names like “success, warning, or error.” So they should be used there as well.

[razzeee]

Which wouldn't be accessible to Protanopia people or similar. I also specifically asked for the end state - as in progress is pretty easy to understand (but I guess adding a pause complicates things).

[ssokolow]

Does the Windows equivalent distinguish them?

From what I remember from last time I used Windows 7, there's just progress and, if user attention is needed, it sets the "needs attention" flag on the taskbar button and displays the completion status in the window.

[Mikenux]

For a DE to properly consider accessibility for progresses, those need to be clearly specified in a portal: their types and different states. How the information is visually presented is up to the DE.

[AdrianVovk]

I like this idea. I mean we could do both, show a notification w/ a progress bar (or multiple notifications w/ progress bars) and then on the app's icon show "overall progress". There was a GNOME Design Whiteboard about having a status icon with a drop down as well to show "system-wide progress".

In general, we should have bespoke UI for certain types of notifications where it makes sense. Progress notifications are just one type that we may find interesting. Ringing alarms, or incoming;ongoing calls, etc we may also want to special case with special UI. Also things like navigation turn-by-turn directions, upcoming travel, etc. For instance, both Android and iOS show a little summary of these kinds of notifications in the status bar and have other places in the system UI where they get special integration