Notification quick reply DBus API
watts.mark2015 at gmail.com
Tue Oct 27 03:30:23 UTC 2020
Thanks for your reply. Allow me to revise and reframe.
What I'm talking about with a "quick reply" interface is a parallel
spec, for, say, org.freedesktop.QuickReply D-Bus interface. I'm
looking at this more from the perspective of "how could this grow?" I
suggested some of that in my last email, but I'm thinking "quick
reply" might come to support rich text, emojis, canned responses, etc.
I think that can and should be a common interface, but I don't think
that needs to be included in the notification spec. What a separate
interface allows for is that if a user has some other way they want to
support a quick reply, they can do that, or if the notification system
supports quick reply, they can do that too. The notification system
can *also* implement "quick reply" which interface we can write up so
that a "quick reply request" has enough info for the notification
system to correlate and combine into one notification item
interaction; however, for me over here with my cool little app that
can translate markdown to format X, I can define my own "quick reply"
implementation that uses my interface, own that interface on the bus
so the notification system suppresses its own quick-reply interface,
and still have the notification system I like and the quick reply
interface I like.
I'm interested in your requirement to "have one code path and have it
handled implicitly": I don't quite understand what that means.
On Mon, Oct 26, 2020 at 10:30 AM David Edmundson <davidedmundson at kde.org> wrote:
> On Mon, Oct 26, 2020 at 2:10 PM Mark Watts <watts.mark2015 at gmail.com> wrote:
>> Hi all,
> Thanks for bumping this topic, it would be good to move that forward.
>> I don't
>> see the advantage of locating this capability in the notification
>> system vs having the source applications themselves popping up their
>> own reply dialog:
> That is the current state if an application wants to have this feature.
> It is worth expanding on why that is problematic:
> - On wayland, clients can't position themselves. This notification will be positioned anywhere and it's effectively garbage.
> - On a phone and other platforms there are even more constraints
> - The current world /is/ fragmented on chat programs again. I personally have 4 open right now. The UX would be messy.
> - We (KDE/Plasma) keep a history of notifications after the popup is gone. If an app did it's own popup we wouldn't get an entry, or if it sends a notification and it's own popup we would get duplicate information on screen.
> For those reasons we tend to see applications prefer to use common specs for current notifications instead of doing their own custom thing.
> Which IMHO is a very good thing, but it means we need new common specs to support additional requirements.
>> applications do want a common way to do...less obtrusive message
>> replies, why not have a "quick reply" interface that's its own thing -
> Something bespoke would be a technically valid option.
> But ultimately you then need to duplicate everything notifications already have: Title, text, actions, dismissal and it puts the burden on application developers to support two modes where only one is available duplicating all notification and action handling code.
> One of the reasons the proposal above ended up as it did, was due to a requirement to make sure clients can have one code path and have it handled implicitly.
> We can debate pros and cons of that, but it comes down to a trade-off.
More information about the xdg