Notifications Portal v2 proposal #983
Comments
|
Hello Jonas, I think this requires organization by use case: progress notifications, alarms, calls/messages (contacts), weather/amber alerts... And those use cases may have other conditions. Examples (non-exhaustive):
|
Could you provide examples of use cases? This appears to be tracking... (apart from tracking when an action is triggered; e.g. clicking on a news notification opens the relevant news and the app is aware of it). Presentation hints and custom methods of alerting: Even though it depends on system policy, I don't see the point of having them when things should be controlled by the user. |
|
Hi @Mikenux,
Fwiw what you're talking about here is some kind of "People" API, that's what iOS and Android use for this kind of stuff these days. I think we'll eventually need something similar, yes. That said, this is is a whole different topic and very complicated problem in itself, which I'd rather solve properly. Once we have a format to expose and store contacts between apps, we can still add that to the notifications portal.
Telling an app that its notification has been dismissed hardly sounds like tracking to me. The current APIs allow for this already, and iOS has API for that as well.
As mentioned in the proposal, it's API to support niche use-cases such as internet radio alarm clocks. There's no way we can integrate playing an online music stream into our API, so in this case, the app has to play the sound itself. The |
|
Yes, I have no doubt that it is complicated, especially for contacts. The goal is to limit things to relevant use cases. Currently, the proposal seems to allow any app to use anything... |
What do you mean by closed? When the app has no windows?
The alternative here is to let apps provide all the data and then decide if and how to show notifications in the backend based on permissions without ever telling the app about the decision. Is there a reason to prefer the explicit permission requests? |
Yup, exactly.
Good question, off-hand the other approach sounds fine to me too. The upside of an explicit permission request would be that we can show a dialog to users asking whether the app may send notifications. I found that dialog quite useful on ios, eg. when you're starting a game, you know right away that the notifications will be ads, so you say no right away. |
Then what about apps running in the background? People use those, we show them in the quick settings menu and they can be interacted with. Why should they not be able to show a persistent notification when they're running?
Apps currently expect to be able to send notifications by default. Does that mean every app which potentially sends notifications will bother me with a popup asking for permission to send notifications? IMO sending notifications should be allowed by default and be turned off potentially in some granular way. You also talk about the concept of important notifications and notifications which can still show when do-not-disturb is enabled. Should that require additional permissions? If a user wants messages from a certain person to show even when do-not-disturb is enabled, that's something the app doesn't have to care about. On the other hand, if the app is warning about an incoming thunderstorm, that's a notification the app should have control over. |
|
For progress notifications, perhaps these should be drawn by the system, not the apps for a consistent interface. By identifying the requested progress notification, the system can decide the UX. Examples: show alarms when appropriate, show file download when app is closed and/or when app has no focus or is covered by other windows. For alarms, it's important that they should register when they start, so that apps can't play sound at will using notifications (given that the app is running in the background). |
|
Everything in the proposal, incl. progress notifications are always drawn by the system. Apps cannot draw any of this even if they wanted, even outside flatpak. |
|
One thing I'm thinking about is whether preventing apps from using progress notifications for content fetching (e.g. fetching mails, news) is wanted. Also, what about "autostart"? In GNOME, background app autostart is wanted, except for app that are closed to continue ongoing activity (e.g. web browser, Builder). However, I mentioned the case of download apps (e.g. downloading torrents), where some downloads may be completed, while others may be paused. So, is autostart still a thing, and does it apply to download apps? |
|
Please keep it on topic. Autostart is a background portal thing and already exists, this is about notifications. |
|
Knowing the autostart experience might be needed to know what differentiation needs to be done for progress notifications... except if it can be done on the background portal side. Examples:
Or are these conditions for the background portal, or something else? (e.g. progress notification + folder location). Just to be sure... |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Well, it's a compromise, I don't see another way of avoiding that apps running in the background just put a persistent notification into the tray to let users know what they're up to. In theory that's the exact use-case covered by https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/150, but then again I'm not a fan of status notifiers either. IMHO apps which don't have a window open should never annoy users in any persistent way, that starts with music players which shouldn't be playing music when they're closed and ends with backup apps which should just quietly and resource-friendly do their job in the background.
Fair point, that is what we're doing right now after all and it seems to be working okay-ish, as longs as we manage to keep apps which are actively hostile towards users (aka financed by ads) away from our platform, I think it'll be fine.
I think it's fine to allow everyone to mark their notifications as important by default, you do want that feature in basically every chat app for example. I think the interesting part here is the "only if explicitly requested by user": I'm not sure how to enforce that other than shaming apps for violating the spec, but if everyone respects that we should be fine? Fwiw, ios does allow this by default, but it can be disabled per-app in the notification settings, I think we could do the same.
The thing is you want the UI for things like marking contacts or chat groups as important inside the app, because that's where users will look for it and that's where the context is. Android kinda moves that UI to the system with its notification channels, and that duplicates things and is generally quite awkward when it comes to features like this. Things obviously get more complicated if we start to have a system-wide API for persons where you can actually mark one contact as important system-wide. In this case indeed the UI would be part of the system, and the "important" bit should no longer be set by the app. I don't see this happening anytime soon though, but if it would I don't think anything in here would stop that in particular. |
The reality is that apps can run in the background, they can show the media controls which pretty much appear as a persistent notification, we list apps running in the background in the quick settings menu and we're adding more context to apps running in the background with the background portal. I don't think it makes a lot of sense to restrict persistent notifications out of all the things to apps with windows only.
Sounds good.
I still think that would be ideal. Punching though do-not-disturb can be really bad if it is unwanted so delegating it to the system makes a lot of sense. Right now we really don't have the infrastructure for it though. So I'm fine with leaving it up to apps as long as we have a way forward to delegate it to the system eventually. |
|
It would be good to know for which applications a persistent notification is necessary, except for media players using MPRIS and progress notifications... |
My only note would apply to this. Do not remove the notification. Make it removable by the user once the app closes. Also, there are valid use-cases for persistent notifications. I can think of many use-cases. , a company that make some smart buttons (Bluetooth switches) used to have a persistent notification to allow you to press digital buttons from your notifications panel on android. I know this is not an actual notification, but it was the absolute best way to do it. Maybe what I'm describing should ultimately be a widget panel, next to the notification panel, but that's a bit excessive. |
Yeah I don't really have a strong opinion on that. I'd be happy to try that approach first, can always restrict it more if apps will abuse it. Then again I am pretty sure they will abuse it if this API gets implemented before the app indicator one.
Yup, that's exactly the point I'm coming from here. That's what persistent notifications are used for on android, but in practice very often what you really want is a proper widget API for apps. Anyway, IMHO this is ultimately a design question and we should leave the answer to the design team and follow that in the API. |
|
On android I understand that there are some notifications that act like widgets, but there are some that are very annoying. And now that I think of it there are some that treat the notification like an app indicator and they are so annoying (zepp life app) .
Which design team? As a swaywm user, I would rather have a solid API implementation that doesn't restrict dedicated notification daemons. It should definitely be coordinated by both sides, but in a DE agnostic way.
I don't understand why this is the case, but I am not so educated on that matter. There are already extensions for that on Gnome and other desktops/wm's have app indicators, so maybe this is not so concerning (?). I don't think I have anything more to contribute. Thank you for opening that issue, I've been waiting for this for a long time. |
It's best not to implement anything about persistent notifications, even after implementing the status notifier specification, at least if GNOME sticks to its position of having "systray" apps (those that want a menu) in background apps UI. The point is that for users, having quick access to the menu is essential, and the background apps UI in GNOME does not allow this. So, because of this, apps will probably still abuse of persistent notifications even if they are implemented afterwards. Also, widgets were briefly discussed in the status notifier spec, but were rejected as not being simple (unless they've changed their minds since then, but I doubt that). @ispanos: Feel free to open an issue about it with case examples. This is something wanted and I guess having a specific API for it shouldn't block the location of these (i.e. widgets can be located in the notification area if it is the wanted UX). |
|
Hi, this is the KDE Plasma notification developers and we like your proposal a lot! Here’s a few suggestions and comments we have: Lock Screen Visibility / PrivacyIt should be possible to tag a notification with a visibility/privacy tag, similar to Android’s visibility property so we can decide whether the notification (and/or how much of it, if at all) is shown on the lock screen, shown during screen sharing, synced to your phone, etc. MarkupSpecify what “markup” is supported here. Probably a small subset of HTML (e.g. Also, we believe that plain text should be the default, with markup as an opt-in flag on the notification. In the past we’ve often had issues with apps either not escaping their text or ending up with double escape. Making markup a conscious choice on the app side (I enabled markup for this notification so now I have to sanitize my input) would fix that. Custom sound fileShould this support XDG sound names rather than only custom paths? On the other hand, a “default” sound could be implied from the "empty string" for ProgressIs there an indeterminate state? Additionally, a Is it in scope to add an additional progress details dict, e.g. "From" / "To" in a copy job, etc? GActionA Especially, given you explicitly mention that portal notifications get revoked when the app quits, so there is no DBus activation happening, it seems like an unnecessary restriction. Unless implied by ImageThe Please specify the wire format used (e.g. can we just send an Both Plasma and Android support a large preview for example for screenshots or received images, which would be nice to have specified here, too. Other
|
This should be up to the portal backend, and ultimately to the user. Just because you dislike background status notifications does not mean that everyone else also dislikes them. |
|
From what I understand, what is NOT wanted is a notification that stupidly stays at the top of the notification list, especially when it is not showing anything (i.e. no specific status). There is the background portal which already handles such "persistence", it just lacks the menu for actions. |
That’s understandable, but at the same time users need chat apps to be able to show a notification (one for each chat message) that persists even when the app is not running. |
I think it makes sense to link the sound to content hint but that's tangential to what #1298 implements so far. Please also note that app developers, with #1298, can also specify themable sound names , which are system provided sounds. (just noticed that i didn't add that to the docs) |
|
@jsparber would it be possible to ensure that it is at least possible, in the future, to support invoking actions on notifications even after the app has exited, and possibly even after a system reboot? In other words, would it be possible to provide each notification with an identifier (such as a 256-bit random number) that will never be reused? |
I think there was some confusion about according to this proposal notifications will have an id specified by the app, so the app has to provide an id which will only exist in the context of the app and may be unique. |
Ah, nice! I suggest adding something like this to the spec
The last bullet is to ensure that conforming applications are at least ready for when it becomes possible for an action to start up an app. |
|
@jsparber: Sorry, I'm confused about what you replied in your comment on your MR and what you replied here. So, does a content hint must be specified? Or does a notification with a sound but no content hint belong to "general"/"information" notifications? Also, can we already know what content hints will be present? |
|
The app ID is needed by most portal interfaces. I propose to have some global |
If this is going to be in the spec, then I think certain |
|
@DemiMarie I think you've perhaps not quite followed? The notification ID is a string provided by the app, and is scoped within an app-id, and what an app does with that is entirely up to the app. For something like ‘System Updates Are Available’ you have absolutely no need of uniqueness: The response to the notification being activated will always be to open the system update page, and if for some reason the notification was already present you new one should replace it, not duplicate — so the id can simply be What really matters is that the id somehow communicates to the app what it should be doing in response to this interaction, and that'll vary app to app — for example a matrix client might use something like A ‘cryptographically secure random number’ would be rather contrary to this goal, in most cases? |
The spec already supports that, that's part of the core design even |
|
@ZanderBrown Ah, I see! In the Matrix case, one would want to have something like |
|
Hello 👋! Tiny bit of motivation for this comment: I'm working on integrating systemd-homed with GNOME as part of the GNOME STF grant. Recently, I've started planning out what GNOME will be doing to provide a lock-screen for users locked via homed: a normal lockscreen cannot work because the user session is frozen, so we need to run a lockscreen outside of the session to facilitate homed's security. This, however, has the potential of breaking apps that may want to appear over top of the lockscreen, which I wanted to avoid. So, I researched the use-cases for apps-on-lockscreen in other OSs, and how the functionality is implemented there. This ended up having a lot of overlap with notifications: incoming calls, ringing alarms, etc are the common use-cases for apps appearing on the lockscreen. My full research can be found here, though I will cover the relevant conclusions in this comment. I've discussed many of these things with @jonas2515, and we seem to be on a similar page about them all. I want to write my ideas down here, to make sure the results of our discussion aren't lost and to collect feedback about it from other projects. CallsOn Android, incoming calls are just apps that put themselves on the lockscreen. On iOS, there's a "CallKit" API that lets apps tell the OS about incoming and ongoing calls. The OS, in turn, can provide a rich incoming call UI, integration with the shell, cross-app call waiting, etc. You can find lots of more detail in my research document. Turns out, this Notifications v2 API almost fully covers the needs of CallKit, so here's a wishlist of things still lacking that need to be in the API spec, or recommended to backends, or etc:
Alarms / Timers / Calendar Events / RemindersOn Android, alarms work similarly to incoming calls. iOS doesn't seem to expose an alarms API. Here's the wishlist of what we'd want for alarms in this API:
Text-to-speechI haven't discussed this w/ @jonas2515 but I think it's a decent idea. Basically, some special kinds of notifications (incoming calls, ringing alarms, calendar events, emergency alerts) could benefit from having a text-to-speech readout of what they're about. I know lots of people who keep their phone across the room, and having the phone yell out "Incoming call from James Smith" every 10 seconds during the ringing is helpful to decide if it's worth getting up to pick up the phone. Here's some examples from my experiences that may be worth copying somehow:
Apps should be required to opt-into this. That way, apps can turn on this functionality on a per-alarm or per-event basis. The notifications API will need to at least be aware of this functionality because it's ultimately in charge of the sounds coming out of the device in response to a notification Note that this is separate from accessibility. We notably shouldn't use this TTS functionality for people using a11y tools because there's often a better pattern to handle that provided by the a11y backend |
|
@AdrianVovk Thanks for your input
I think displaying full screen notifications fit pretty well with the direction the content type property goes in. I think rising an app on top of the lockscreen can also work but it's gonna take a while to get to that point :)
Interesting idea, apps should be able to implement that via setting a custom sound file. Obviously needs a lot of work on the app site. But in future it may be interesting to explore 👍 |
This takes the discussion in flatpak#983 and turns it into an actual possible v2 of the notification interface. The permission part was intentionally left out since it's tangential to the new properties and features proposed here.
This takes the discussion in flatpak#983 and turns it into an actual possible v2 of the notification interface. The permission part was intentionally left out since it's tangential to the new properties and features proposed here.
|
Question: For themes, why are multiple icon names defined if only one is used? |
|
Coming to this discussion a bit late, can we consider adding support for newlines in notification body text? In the current implementation, newlines are flattened to spaces. It makes sense for a collapsed one-line view of a notification, but there are cases where some simple formatting can go a long way to improving readability. This doesn't lead directly to large notifications that use a lot of space -- I've seen mention previously of limiting expanded notification bodies to 6 lines of text and that doesn't seem unreasonable. Where I'm coming from: I want to display a notification along the lines of:
With the current implementation, it's a single-line river of text:
|
|
I have just this morning learned about the existence of the "Whiteboards" project. Would it be appropriate to open an issue there describing this request? |
|
Personally I haven't explored the code but if it really strips new lines the it's going to be very annoying. I believe this should be decided on shell level while portal should relay the text just as is. |
|
@ilya-fedin I believe this is the offending section: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/messageList.js#L546-551 This control is used by the notification code, which creates a subclass called https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/notificationDaemon.js#L449-456 You can see this in action on currently-released Ubuntu versions. In one terminal, run But the notification which appears shows "a b", all on one line. |
|
Ah, so it's not related to this proposal? |
I didn't see that here. However, in GNOME there is, but this is not a GNOME-only space here. Your issue can be discussed at https://github.com/flatpak/xdg-desktop-portal/discussions for further discussion if necessary. |
So, I'm new to this and kind of stumbling in the dark. I initially raised my concern in a GNOME desktop specific space, and the answer was, "Well, the current implementation matches the specification." So my next question was, "Where is this specification?" And the first answer I got to that was this issue here. I'm not in a position to judge how much that makes sense. Just, I was sent here to make my proposal about notifications. :-P |
|
I guess that was "we're allowed to do this so we're doing this" in formal language |
|
Hello, sorry for being late, but are there any interests in having slider/progress bars in the notification portal? This would be useful for file operations, download operations, upload operations and many more. |
|
I think this can be closed since most features landed now and the remaining things that were discussed here are collected in #1495 |
github-project-automation
bot
moved this from In Progress
to Done
in XDG Portals workboard
and others
Quick introduction for those who don't know me: I'm Jonas (aka verdre) from the GNOME community, mostly working on gnome-shell/mutter but also across the stack to get things ready for phones.
The notifications portal is currently of very limited use for apps with more advanced notification needs, especially with smartphone use-cases in mind.
Here's a proposal for a new version of the notifications portal, trying to kickstart development and open room for discussion.
Things we want
Things we don't want
Proposed API
Permission requests
RequestNotifications()method.AddNotification()can fail.Content Hints
Used for all notifications that need specific handling, eg.
There are three different namespaces that any hint must adhere to:
class: What type of content the notification is. Possible hints are standardized with the protocol. Only a singleclasshint may be used per notification.class.im.messageclass.alarm.ringingclass.call.incomingclass.call.ongoingclass.call.missedclass.weather.warning.extremeclass.cellbroadcast.danger.extremeclass.cellbroadcast.danger.severeclass.cellbroadcast.amberalertclass.cellbroadcast.testclass.os.battery.lowclass.browser.webNotificationimportant: Marks the content as important. This might make the system present it differently, for example ignoring the Do Not Disturb setting. May only be used if explicitly requested by user, for example when marking a contact as important. Anything else that the app considers important must use an appropriateclasshint instead.custom: Custom application-defined tags, unlimited number can be passed.Requests and Responses
Requests and responses are the new API for actions.
responseAction) that's activated on the applicationRequests have an application-defined
requestId (s)andrequestParams (a{sv}).The response object is passed to the
responseActionGAction as the parameter (formatssa{sv}:notificationId (s),requestId (s),responseParams (a{sv})). TheresponseParamsare usually empty and only set when using a preset request ID.Preset request IDs
There's special request IDs for common requests in the
presetnamespace, proposed IDs (standardize with the protocol?):preset.onClicked: Get notified when the notification itself (so not a specific request) has been clickedpreset.onDismiss: Get notified when the notification is dismissedpreset.accept: For accept/decline requestspreset.decline: For accept/decline requestspreset.cancel: Cancelling an ongoing eventpreset.done: End an ongoing eventpreset.im.replyWithText: Inline replies for chat apps. Hints the system to show a reply button with the notification that allows entering text. In theresponseParams, areplyText (s)will be set.preset.im.muteSimilarNotifications: For chat apps that might send lots of notifications. AschatName (s)parameter, pass a string describing what is going to be muted. The string should fit into "Mute notifications for %chatName?". In theresponseParams,forDurationSeconds (t)will be set.preset.call.toggleSpeakerphone: To be used by call apps. PassspeakerphoneInUse (b)in therequestParams.preset.call.returnCall: To be used by call apps.Presentation hints
Presentation hints allow configuring specifics of how a notification should be presented. The system may ignore those depending on its policy.
Supported presentation hints are listed in
presentationHintsfield returned byGetCapabilites().Standardized hints:
sound (s): Specify a custom sound file to play, set empty string to play no sound at all.vibrationPattern (s): Vibration pattern to use according to Web Vibration API specification, set empty string to request not vibrating at all.ledColor (s): Notification LED color as 6 digit hexadecimal value, set empty string to request not lighting the notification LED.dontShowBanner (b): Passtrueto avoid showing the notification banner and potentially disrupt the user.dontAddToTray (b): Passtrueso that the notification won't be added to the notification tray.presentNonDisrupting (b): Passtrueto avoid all ways of actively alerting the user.Custom methods of alerting
Apps may use custom methods of alerting the user, for example to play audio from a special source like an online stream of a radio station.
AddNotification()returns anappPresentationPolicy (s):mayNotAlert: The app may not alert the user in any way.mayAlertDisrupting: The app may alert in a way that is disrupting to the user and only the user, eg. using vibration.mayAlertVeryDisrupting: The app may alert the user in a way that is disrupting to the user and potentially to other people, eg. by playing a sound on the speakers.DBus API
Methods:
RequestNotifications
GetCapabilities
AddNotification
RemoveNotification
Open questions
How would I do x with this?
Create and ring an alarm clock
Create "next alarm" notification a few hours before alarm
class.alarmpreset.cancelrequest to allow removing alarm againpresentNonDisruptingpresentation hint so that the notification silently shows in the trayWhen alarm rings, remove old notification and create a new one:
class.alarm.ringingpreset.doneandsnoozerequestsisPersistentto truedontShowBannerpresentation hintOn response:
preset.doneis invoked, remove notificationsnoozeis invoked, remove notification and go to 1)Notifying an incoming call
Create the notification
class.call.incoming, this magically makes the system:preset.acceptandpreset.declinerequestsisPersistentto truedontShowBannerpresentation hintHandle responses and missed call
preset.acceptgets invoked, accept the call and update the existing notificationclass.call.ongoingpreset.cancelandpreset.call.toggleSpeakerphonepreset.denygets invoked, deny call and remove notificationclass.call.missedisPersistentto falsepreset.call.returnCallThe text was updated successfully, but these errors were encountered: