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.

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

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

In T11875#229181, @nicolasfella wrote:

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. https://developer.android.com/reference/android/app/NotificationChannel on Android's properties on the channels.