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]

One could argue that this is up to the shell to deal with - it knows what notifications are seen or unseen, and where they came from. It should be able to match them up appropriately, I'd think?

[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.