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 "ü"
  • 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)

Related Objects

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