(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
- 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.
- 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
- 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
- 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 "ü" (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
- 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)