(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/com.android.fooapp/12345` 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 `ü` stays `ü` 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
**Other**
* "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)