Plasma/Notifications

This page contains some ideas how to improve the Plasma notification system in order to move it forward and helping the user to become even more productive.

This page assumes the status quo as of Plasma 5.7 and org.freedesktop.Notification 1.2 specification. It only describes changes to be based on that, unless further clarification is needed.

Note that the 1.2 specification contains extensions proprietary to the GNOME project but this page treats those extensions as standardized functionality usable without further implications.

Unused Standardized Features

This section lists features that are currently part of the aforementioned specification but are currently either not provided as an API by the KNotifications Framework or ignored by the Plasma notification implementation.

Urgency

A notification may carry an “urgency” (byte) hint:

• 0 – Low, “Konqi signed on”, “You just plugged in your AC adapter”
• 1 – Normal, “You have new mail”
• 2 – Critical, “Battery level is critical”

Plasma notifications could gain the ability to filter out notifications based on their urgency, perhaps either as a slider or a “Priority / Do not disturb” mode.

“Low” notifications like the example one are often pointless and could be disabled by default.

In order to avoid potentially revealing moments, Kwin does not raise windows of notification type above fullscreen windows, such as video players or ongoing presentations. A “Critical” notification might be worth displaying regardless.

It is up to the application developer to decide which urgency to assign.

If urgency is not specified, the notification should be treated as one of Normal urgency. Urgency might also affect the order in which the notifications are shown in the notification history.

Category

A notification can be assigned a Category. It can be used to provide more concise actions and grouping or the ability to filter out all notifications of a certain group regardless of which application emitted them.

The notification service might choose a different appearance for a notification based on its category. For instance, an incoming call notification might get a green “Accept” and a red “Decline” button with the user picture filling the notification window. A “User is now online” notification instead might get a very compact and unintrusive layout.

Action Icons

Currently, Plasma only shows the notification action text as actions are transfered as a string-list of alternating action Ids and action labels. A server might attempt to use the action name as ID for the action whereas Knotification always uses seqential Ids.

With the VDG strongly in favor of not using icons on buttons, it might not be worth implementing this in KNotification as it complicates the mapping code between invoked action and the signal the application is sent.

Resident Actions

Plasma currently removes actions from a notification, even persistent ones, once one has been triggered. TODO write more

New Features

This section lists features that cannot currently be provided in a cross-desktop way using the specification but require proprietary extensions in a KDE namespace.

It needs to be ensured that applications running in an environment without such extensions are not jeopardized and either an automatic fallback (determined by querying the notification server’s Capabilities) is in place or the offending feature is disabled.

Quick Reply

This enables the user to reply to an Email or SMS from within the notification. A “Reply” text field might be placed in the notification window whose content is eventually sent back to the application through the notification server.

This is not meant as a replacement for the Quick Chat applet of KDE Telepathy but as an easy way for other applications to provide a quick reply mechanism.

Notification windows currently do not accept focus which prevents users from entering text. Means of changing this need to be evaluated that do not cause the window to steal focus which was the reason for setting this particular window flag in the first place.

Notification services that do not support this simply won’t provide such functionality.

File Path

This allows an application to annotate a notification with a specific file path which the notification service could use to provide a richer/larger thumbnail and/or provide a common “Share” pattern to upload a file to a web service or send it to a contact, or simply open it in an application. Also, the ability to drag the file from the notification window elsewhere, e.g. into a web browser window, could be implemented.

This is particularly useful for notifications that notify about files being created, such as a “Screenshot Taken” notification, or a “File transfer from your phone finished”.

If the given path points to a directory rather than a file, opening said folder in a file manager could be offered. Perhaps even multiple files/folders could be passed, allowing us to replace the awful “File transfer finished” notification that currently just opens the last folder transfered instead of the parent-most folder that was actually copied.

Notification services that do not support this simply won’t provide such functionality.

Contact ID

This allows an application to annotate a notification with a specific contact ID which the notification service could use to provide more information about the contact this notification is related to. For instance, a notification about an email received by a certain contact could show his or her avatar with online status alongside options to start an IM conversation. This would use the KPeople Framework for querying contact information.

It needs to be discussed how it can be ensured that offered actions are sensible, ie. an incoming call from a contact won’t offer to start an IM conversation instead. Perhaps the offered actions need to be based on the category of the notification, cf. above.

Notification services that do not support this simply won’t provide such functionality.

Lock Screen Notifications

For privacy reasons currently no notifications are shown on the lock screen. A hint could be added to the notification that it may be shown on the lock screen. This needs to be configurable by the user and stored through notifyrc and the default needs to be evaluated very carefully.

A notification cannot be interacted with on the lock screen, neither closed, nor an action triggered. It could be considered showing the actions and upon invoking them focusing the password field and triggering the action after the session unlocks. As there are currently hardly any persistent notifications, there’s usually not much to show on the lock screen and since the notification UI code is quite complex, it might not be worth the effort to implement this feature.

Re-thought Notifications

This section lists notifications that we currently show to the user and contains ideas on how to improve them, make them less intrusive, and/or get rid of them entirely.

Completed file transfer

Notifying about a completed file transfer in a persistent notification is absolute overkill.

A non-persistent one is okay so that users know they can now work with the file at the place they copied it to, but having it persistent makes no sense, because if you return to your PC after a while and see neither an ongoing file transfer nor an error message, you know it has completed successfully.

Error messages should be persistent, however.

As a general rule: Persistent notifications should only be used to inform about something which is - Important - Unexpected

Crazy Ideas

This paragraph lists some crazy ideas that we could toy around with:

• Notification sidebar
• Place an icon in tray for every application that has a notification (cf Android)
• Keep all notifications in a backlog but don't annoy with that (ie. no stupid "1" icon if it's irrelevant)
• Better notification merging (eg. for new emails)
• Notification in backlog but not as popup (new song popup is annoying but might be handy to have a history of that?)