Notification quick reply DBus API

[Mark Watts]

Hi all,

New to the list and the XDG specs, but I've looked into what's
proposed and have some doubts about the use case for the "quick reply"
in a notification system itself. My thinking on notification systems
is that their whole thing is getting the user's attention for some
event and providing enough info for the *originating application* to
help the user resolve the event (e.g., "open file location"  for a
downloaded file). Adding an input suggests to be an extension in the
scope of the notification spec that quickly becomes painful once the
application developer decides to go this route. A couple undesirable
things I'm imagining with the current proposal:

1) The user starts typing in their reply, gets about two sentences in,
realizes they actually need a more nuanced reply and want more
formatting, but the notification system doesn't know what the
originating application supports because there's no hints for that.
Assuming the notification system's quick reply supports text selection
and copying, the user must copy the text and invoke the default action
and paste in the text -- there's not a secondary action for taking the
current input and adding it to the default action.

2) As I think is hinted at in [matthiasclasen's comment] on github
about serialization and robustness, text may not be the only input an
application wants for a quick reply. For instance, a calendar
application may want a drop-down menu of times in the future for a
"snooze" input for a meeting notification. Given the variety of
applications that may have cause to get a user's attention, favoring a
"message reply" input invites more folks to think their use case is in
scope for the notification spec. This can make the notification spec a
focus for a lot of non-notification effort and coordination,
lengthening the time to get desired features in place.

My main point is that the notification system, since notionally it's
distracting the user, works better if it stays focused on helping the
user decide whether or not to engage further, taking them out of what
they had been doing. A "quick reply" starts to take scope from the
application that it can't handle effectively: Might as well give it
over to the application at that point.

I avoided, above, saying what *should* be done alternately. 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: Do we need to make the applications uniform in how
they solicit replies from notifications? How many different chat or
messaging applications is a user going to have on one machine? If
applications do want a common way to do...less obtrusive message
replies, why not have a "quick reply" interface that's its own thing -
if the notification system wants to incorporate an implementation of
that interface, it could do so. The spec for this interface could
reasonably take all of the scope for replying, like supporting a basic
or optional set of formatting, continuing to the full application with
a partially completed response, or plugging in canned responses (or
A.I. generated responses).

[matthiasclasen's comment]:
https://github.com/flatpak/xdg-desktop-portal/issues/485#issuecomment-630366590

--
Cheers,

Mark W.