mck182 added a comment.
> I don't think that KNotification as a framework should hide this feature from the developer. I, on the other hand, don't see why the developer should need this feature; as I said before - there's no scenario where the app should want either really short or really long time on the screen - this should always be fully up to the shell displaying the notifications. If you do need to have the notification bubble on the screen for really long time, then imho that's a wrong solution to the problem it'd be solving. And that applies to this case as well. KDE's Bluetooth integration is solving the same problem (pairing devices) and it uses a dialog, which imho makes sense, because with notification you're supposed to inform the user that something has happened and he may or may not react to that something, while what you're doing requires direct user interaction and what you're trying to solve is the possible lack of that direct interaction. So I honestly think that a notification is not even the right approach here altogether. > they do that using the notifications cross-desktop standard. So I wouldn't criticize Gnome for doing their own thing here. Oh really? :) Ever wondered why the spec you're referring to is full of only Gnome's extensions and is hosted on Gnome's servers? It's because Gnome considers the Galago project, the actual cross-desktop notifications project, dead. They took over libnotify and they consider that implementation to be the canonical upstream for the specification. In other words, Gnome has full control over that spec, can do what they want and can just as easily block any of our contributions. Sure, it is based and backwards-compatible with the cross-desktop standard, but it stopped being actual cross-desktop standard long time ago. If you feel like changing that, this would be a good start: https://bugzilla.gnome.org/show_bug.cgi?id=748145 > @colomar: This would be perfect, but it would need a whole lot of work from both the desktop environment and the application side. It's actually not that hard as far as the last three points go. This can be fully implemented in the notification's server (ie. Plasma) and the apps changes would be minimal. I even had a branch doing exactly that, I just never had the time to finish it. But basically the idea is - every new notification that arrives to the server is directly mapped to a KSNI - title to title, text to subtitle, actions to SNI actions. The lifecycle is a bit tricky (eg. when it is not needed anymore) but still can be done. I meant to mostly mimic what Android is doing. The only part remaining to solve is the drawer that has all the SNIs and their action in some sensible way. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: colomar, mck182, #frameworks
