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. _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
