Re: Notification quick reply DBus API

David,

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 <[email protected]> wrote:
>
>
>
> On Mon, Oct 26, 2020 at 2:10 PM Mark Watts <[email protected]> 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.
>
>>
>> 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 -
>
>
> 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.
>
> David
>



-- 
Cheers,

Mark W.