KNotification v2
Open, Needs TriagePublic


(mostly a copy of the knotificationsv2 etherpad)

This is a collection of requirements/features/ideas for a rewrite of KNotifications with Qt6/KF6 in mind.
Unless there is something in Qt6 that influences the API design in a major way we should already introduce it in KF5 so we can port code before the major Qt6/KF6 work.

Don't auto-delete notifications

  • They're not jobs.
  • Could allow features like revoking notifications after they expired and triggering actions from the history.
  • Also reduces surprises when using KNotification. Not storing it in a QPointer<KNotification> is a common mistake

Unique identifiers?

  • Allow to revoke notifications after notification "expired" or even anytime after process died or reboot, e.g. network/wifi/UUID/connected and then NM could just revoke network/wifi/*/connected when it is no longer connected,
  • or just network/connected and then that will replace any previous network/connected notification?
  • e.g. battery/low and then it could just revoke it when AC is plugged in
  • e.g. chatapp/CHANNEL/newmessage and then it could just revoke chatapp/*/* when the user focuses the channel
  • Maybe even with some auto-revoke QWindow focus event magic like the current KNotification has (which doesn't work :D)
  • or e.g. kdeconnect/ so that it can just keep the notification list in sync

Also ties in with "context", so that chatapp/$PERSON/* could be configured independently from chatapp/global/* or something. Also we have "eventIds" right now already.

Support categories?

  • Somewhat ties in with unique identifiers? Maybe supplements them. e.g. "network.disconnected"
  • Could be useful for providing different layouts for notifications, e.g. incoming calls or picture-heavy stuff, not sure how useful that would be.. probably not very

Rework sound

  • use native Windows/macOS/Android sound
  • implement FDO sound spec in Plasma:
  • There's "sound-name" (sound schemes!), "sound-file", "suppress-sound"
  • move sound playback there? At least for everything that spawns a Plasma/FDO notification popup
  • then kill phonon backend
  • then kill Canberra backend? Or keep it as fallback for *nix platforms without sound in notifications

Proper platform backends

  • All the platform backends like Android, Windows, macOS are just shoehorned ontop of the "Popup" action. Do this properly, move from "Action"-driven to platform backends.
  • Consider space bar heating removal

Reduced dependencies

  • Don't depend on DBus except for FDO backend
  • Don't depend on widgets, use optional QWindow instead for window raising
  • Don't depend on KCodecs, it is only used for stripping HTML - Plasma's notification sanitizer doesn't actually resolve entities (and the spec is very vague, "subset of HTML"), so &uuml; stays &uuml; and doesn't turn into "ü" (done)
  • consider QSystemTrayIcon as a replacement for KStatusNotifierItem (needs some work on QSTI) or at least move it out of the repo (has widget dependencies etc)
  • Let dave figure out QPT inheritance stuff so we can use qgenreicunixdbusblablathing
  • ksni potentially doesnt work well with sandboxed apps
  • Kill KPassivePopup D22544
  • Can we make it Tier 1? Would make it more interesting for third-party users. Wasn't there even an effort for a Qt notification module? (Qt Application Manager is probably not it...). Most 3rd party projects just use libnotify which is C and has less deps than any Qt lib

New APIs

  • Quick reply: Windows, macOS, Android and soon(tm) Plasma support quick reply. Have API for that in KNotification and a fallback dialog for platforms that don't support it
  • Add KNotificationCapabilities class (?) to query notification server / backend capabilities, so app can know in advance if it supports stuff like "origin name", html markup, etc
  • Make setting HTML/rich text notification body text a conscious decision by the API user (setText vs setRichText or similar)
  • Resurrect KNotificationRestrictions for notification inhibitions
  • Convenient "bind to this window visible" feature


  • "Proper" backend for sending notifications to phone via KDE connect?
  • Plasma notification multiplexer/forwarder (oh kuiserver all over again)
  • maybe needed for screenlocker anyway?
  • Propose FDO to move it to them and clean up dead stuff in the spec (make 1.3? with history in mind?)
  • Figure out accessibility

Make it usable without the KNotifyConfig stuff. It's mostly irrelevant for non-Plasma platforms
Especially make sure that a notification doesn't randomly not show just because notifyrc is missing or misconfigured. Make notifyrc/pre-declaration of events optional rather than core requirement?
Make notifyrc based on desktop entry rather than application binary name (e.g. org.kde.konversationrc instead of konversationrc with DesktopEntry hint)

broulik created this task.Oct 14 2019, 10:13 AM
ognarb added a subscriber: ognarb.Oct 14 2019, 5:00 PM
broulik added a comment.EditedNov 24 2019, 3:24 PM

Braindump after call with dfaure and nicofee:

  • ignore app restarted/not running case with global identifiers from above
  • Is a normal QObject
  • delete object implies closing notification
    • since you cannot invoke actions when object is deleted
    • encourages users to explicitly clean up their notifications appropriately
      • e.g. close "connected" notification when disconnecting wifi
      • opening discover would revoke "updates available"
      • plugging AC would revoke low battery notification
      • turning on Numlock revoke "numlock turned off" in kaccess
      • etc etc
    • add setAutoClose(false) or similar if you really want a fire and forget
      • "compositing reset" would be fire and forget because user cannot do anything about it
  • even if closed by user object stays around but becomes invalid
    • e.g. has state of "on screen", "in backlog"/"expired", etc
  • have Notify replace_id replace not change order (i.e. remove "updated" timestamp from notification filter lessThan)
    • more common use case is delete old notification object and make new one for drastic changes (semantic-wise, like "num lock off" vs "on")
  • Drop most of event config
    • Instead add signal for app to open app notification config (settings action used in Chrome)
    • Figure out plasma workspace notification config, e.g. a place where to turn on/off login sound, warning sounds, etc
      • Maybe kill notifyrc for apps and keep it around for daemons and what not which don't have UI
      • Apparently Android requires some ahead of time configuration, too, so perhaps keep this somehow

Other changes/comments:

  • QWidget → QWindow
  • KWindowSystem::activate → window->activate() or something
  • Make setText and setPlainText separate, usually you don't want rich text
  • What about KCodecs, used for escaping. Plasma uses QXmlStreamReader which chokes on HTML but spec says "XML-based", so, do we care?
  • What about KMessageBox sounds? Currently there's a plugin that it uses to play the sound or something
  • What about popup fallback? KPassivePopup dead... QProcess::startDetached("xmessage")? :-P

See if it's possible to have activate *not* imply close.
The notification server currently sends a close after an activate. I tried to not do that but that caused some issues of notifications not being revoked. I don't recall whether that was just KNotification relying on this or if it was also third party clients.
Ideally, user clicks notification, activated is invoked, chat window or whatever gets focused, client then revokes notification explicitly.
Has to be tested.

nicolasfella added a comment.EditedMay 1 2020, 9:58 PM

More random thoughts:

  • KCodecs dependency is dead
  • KWindowSystem dependency is almost dead
  • Fallback to KPassivePopup is dead D29021
  • KPassivePopup will be deprecated D22544
  • Having a KNotifyConfig is mandatory for a few things:
    • Determining the actions/plugins. We want to kill those anyway so we could fall back to Popup if we don't supply actions
    • Determine app name, to be sent to server: We could default to QGuiApplication::applicationDisplayName() with a setter to override, e.g. newmailnotifier wants itself to be seen as KMail or KDE Connect as some Android app. Could replace x-kde-display-appname hint
    • Deternine app icon. Could read from desktop file, have a setter or just be empty
    • On Android we use the event data to create a Notification channel. This could be replaced by some category setter or default to "Default" or similar With these changes I think the notifyrc could be optional, then we can see what is actually worth saving from there
This comment was removed by broulik.

Additional thoughts:

  • KNotifyConfig should be removed in its current form, notifyrc shouldn't be mandatory
    • Android mandates notification channels now
    • Idea: Make use of fdo category for standard events like new email
    • Idea: Have app define actions in code somewhere (like kaboutdata at beginning?) and send all custom categories as hint over when sending first notification?
    • KCM already keeps track of apps that sent notification for configurability, would be extended to keep track of categories, too
    • Idea: Make filtering by category also on server side, like already done for per-app, so app always sends configured notification and then server discards it based on settings.
  • Apps usually have own mute feature or config for notifications. Most apps currently either have only one event defined or all on by default. Only notable heavy users of notification configurability is anything Konsole (including Yakuake) and chat apps (Konversation, Quassel, Kopete, Teletpathy)

idea: Have app define actions in code somewhere (like kaboutdata at beginning?) and send all custom categories as hint over when sending first notification?

That would make it depend on KCoreAddons, right? That's something we want to avoid

I meant that KAboutData as an example of something an app uses early on app startup :) KNotificationv2 should provide some categories class where app puts in all of the categories. basically notifyrc except at runtime

D29405 shows that a notifyrc-less KNotifications is possible in principle.

On Android we still have the problem that notifyrc supplies the needed channel name/descriptions.

Possible solution could be the aforementioned "Have app define actions in code somewhere", e.g. KNotification::addChannel("some_id", "Name", "Description"). Could fall back to a default channel if none is set

vkrause added a subscriber: vkrause.May 4 2020, 2:05 PM

D29405 shows that a notifyrc-less KNotifications is possible in principle.

On Android we still have the problem that notifyrc supplies the needed channel name/descriptions.

Possible solution could be the aforementioned "Have app define actions in code somewhere", e.g. KNotification::addChannel("some_id", "Name", "Description"). Could fall back to a default channel if none is set

Downside of this is it removes the ability to easily add additional properties on the channels, the config file kinda offered a generic key/value interface to extend this. See e.g. on Android's properties on the channels.