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 <zbr...@gnome.org> Maintainer: Dia Diagram Editor King's Cross / KGX GNOME Design Tooling (Icon Preview, Colour Palette) Co-Maintainer: GNOME Clocks en_GB Translation Team Me ≢ GNOME
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg