Notification quick reply DBus API

Zander Brown zbrown at
Wed Feb 5 15:01:24 UTC 2020

Hey again

> And how should that hint look like? Will it say "I want this action to 
> do a quick reply if you can"?

Right, I imagine just

"quick-reply": 1

> Either way, a client has to check for it being supported before using 
> it.

Actually no you don't, unsupported hints are just ignored. Not sure anyone has
ever made use of the category hint but nothing explodes when you specify it

To quote the spec:

    Both sides should assume that hints are not passed, and should ignore any
hints they do not understand. 

> Otherwise with my proposal they will just not connect to the signal 
> and never get a reply

Except you've now had to sniff the server before sending the notification
otherwise the server will happily present a broken action

> or in your case they will get an action 
> invocation with an ID they don't expect: "inline-reply::Some Text" 
> rather than the "inline-reply" they added.

Well if you where using using inline/quick replies you would be expecting a
inline-reply::* invocation (though this would possibly require $notifyclient to
do work to support it)

> Given this, I think a dedicated signal is more explicit.

Possibly, but as mentioned it only makes sense (at least to me) when combined
with a hint rather than an action

And as you've updated the interface with an extra signal to subscribe to you
still need to update $notifyclient to handle that so neither way is perfect

Zander Brown <zbrown at>

  Dia Diagram Editor
  King's Cross / KGX
  GNOME Design Tooling (Icon Preview, Colour Palette)

  GNOME Clocks

  en_GB Translation Team

  Me ≢ GNOME

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the xdg mailing list