Skip to content

[Notifications] Support persistency

Kai Uwe Broulik requested to merge work/kbroulik/noti-persistency into master

This allows a client to mark a notification as "resident" which means it will not be closed by the sever when expired or an action is invoked, thus transferring full control over notification life time to the client.

A notification popup still times out as normal (unless persistent, of course) but the notification remains alive until the client revokes it or a user explicitly closes it.

It is opt-in so that a client can expect the notification lifetime to be indefinite and explicitly close it when an action is invoked on its end.

Needs frameworks/knotifications!35 (merged)

  • Made a notification with noti->setHint("resident", true); and was able to invoke actions on it as many times as I wanted, even from history, and also update the notification in-place as a result of clicking a button
  • transient isn't actually wired up as KNotifications used to send that out unconditionally and many other notification services have also stopped checking this property. We could revisit that at some point.


  • Needs a lot more testing with clients. I know that for instance Chrome sets the timeout to 5s instead of 25s once server claims persistency support but does not actually do anything (it does not set resident)
  • Haven't tested with any genuine client that uses that, didn't find any. I suspect there might be some GTK apps that do? Alas, didn't find any mention of persistency/resident in GIO either, just libnotify

(All of this just so I can avoid discover!91 (closed) :D)

@bshah @nicolasfella

Edited by Kai Uwe Broulik

Merge request reports