[Differential] [Commented On] D4663: Allow setting the timeout value.
mck182 added a comment. To expand on what Thomas said, SNI is just a specification, the implementation is fully up to the shells. We chose to implement it as systray icons, but some innovation there could take it to much different places. So far nobody has come with ideas of what that innovation may be, however. As for Gnome and their standard, well from your point of view it may all seem great, but with couple years of maintaining our notification system I will just disagree with you and leave it there because this is not the place for this conversation. 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
[Differential] [Commented On] D4663: Allow setting the timeout value.
colomar added a comment. > even Windows and Mac have deprecated them in favor of persistent notifications! > Not only it's already implemented, but also it is what every major desktop and phone OS out there already use! SNIS != those legacy systray icons which were rightfully abolished. Systray icons are shown as long as an application is open (and with that they turn the syrtray into a secondary taskbar which makes no sense) An SNI may look the same, but the big difference is that it is only shown as long as a notification is present, so when used correctly, they do not clutter your systray with icons but instead give you a good overview of which applications want your attention, without ypu having to open a drawer which shows all notifications. I admit that what we currently have is more of an interim solution towards what Android does, and in the end SNIs should be merged with persistent notifications to get the full experience, but giving every application control over precisely how long a notification should be shown is not a good step in that direction. 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
[Differential] [Commented On] D4663: Allow setting the timeout value.
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
[Differential] [Commented On] D4663: Allow setting the timeout value.
colomar added a comment. I agree that what Android does makes a lot of sense. What they have is - a permanent icon in the top bar for each application that still has an open notification - basically an SNI, minus the direct interactivity (which makes sense given that tiny icons are not much fun to interact with on a touchscreen) - a drawer that shows all notifications that are still valid (plus the same on the lockscreen if enabled) I have not seen a better notification system anywhere so far, to be honest. It would make perfect sense for me if Plasma did exactly the same, but we'd still need to change a couple of things for that to work: - We'd need a drawer to show all notifications that are still valid (similar to the notification history that we had in Plasma 4, but with some very important differences, see below) - We'd need to automatically create an SNI for every application that sends a notification - Notifications would need to be grouped by application (the notification drawer on iOS shows what a horrible mess you get if you don't do that) - Notifications would need to be cleaned up by applications when no longer needed (this would need a new API for applications) This would be perfect, but it would need a whole lot of work from both the desktop environment and the application side. As long as we can't get there, I agree with Martin that an SNI is a better solution than a permanently shown popup notification, as it attracts attention without covering anything on the screen. 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
[Differential] [Commented On] D4663: Allow setting the timeout value.
albertvaka added a comment. I agree that just rising the timeout is suboptimal but I still like it better than a modal dialog... Actually, notifications were invented as a way to avoid harassing the user with modal dialogs when apps need attention. Apart from that, and even if we end up implementing this in a diferent way for KDE Connect, I don't think that KNotification as a framework should hide this feature from the developer. Regardless of the notification server implementation, the underlying protocol that KNotification exposes does allow defining a timeout. And, about SNIs... It's true that they have a title, text and actions like notifications. But they also happen to be represented in every major desktop (eg: Windows, MacOS, Gnome, Unity and Plasma) as an icon in the system tray that you have to right click to access a context menu with the actions (unlike notifications). Are you sure that's what Android does? Gnome implements something much more similar to the notification systems nowadays present in Android and iOS (and even Windows and MacOS, which are trying to deprecate their system tray icons), and they do that using the notifications cross-desktop standard. So I wouldn't criticize Gnome for doing their own thing here. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
[Differential] [Commented On] D4663: Allow setting the timeout value.
mck182 added a comment. Well, I would argue that Android is using exactly indicators which we know as SNIs. It's the same thing - it's an icon in your top panel and when you pull the panel down, you see the title, text and available actions. This is _exactly_ what SNI does, it just so happens that on desktop the representation is always an icon with context menu. It has title, text and actions and is often accompanied by a popup notification. That said, I realize you want to target as broad userbase as possible, but if Gnome decides to not be cross-desktop compatible, well screw 'em, their fault. It bothers me that people always have to find alternate, many times sub-par solutions and the reason is "Gnome" that never wants to play along with about anything. But I digress. I still think having a notification sticked to the screen with indefinitely-high timeout is not the solution. If only for the unpredictability of servers. Given the user has to initiate the pairing and the user is then expected and required to complete the pairing, how about using some modal way to confirm the pairing? Like a popup dialog? I mean if the point of the interaction is to complete the pairing and if it's imperative that the pairing completes, then just put it in front of the user square and center to confirm. Raising the notification timeout for this to me is a workaround at best. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
[Differential] [Commented On] D4663: Allow setting the timeout value.
albertvaka added a comment. I don't think indicators are the future of notifications :/ If you have a look at modern systems like Android (which had the luxury of designing a notification system without having to think about legacy), they have nothing like app indicators: they use persistent notifications instead. Gnome has also taken that way [1], so if we make appindicarors a core part of kdeconnect, we will never look native on Gnome... I'm trying to find a different solution. [1] https://wiki.gnome.org/Design/OS/MessageTray/Compatibility REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
[Differential] [Commented On] D4663: Allow setting the timeout value.
mck182 added a comment. I see your usecase, but I think there might be better solution overall and that would involve not actually depending on the notification. As you say, servers should enforce maximum timeout, Plasma does just that and there's no safe way to predict what other servers would do. You could simply create a StatusNotifierItem with "demands-attention" state, that would cause it to blink, pulse or do whatever the implementation does. The good thing about this is that this would be animated in the screen basically forever while not being obtrusive. In Plasma it even raises a panel that is hidden. It's also fully cross platform and in fact, it is where the persistent notifications should evolve into (where persistent is the persistence you're looking for in your usecase). This would be in addition to the regular notification, not its replacement. Clicking the SNI would result in the exact same action you'd get from the notification. Plus, KSNI lives in the KNotification lib, so no new dependency. How's that? REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
[Differential] [Commented On] D4663: Allow setting the timeout value.
albertvaka added a comment. I understand the potential of it being misused, even though I don't think we should treat developers as if they didn't know what they are doing. Also, if we want to have a maximum timeout, this is something that should be enforced on the server (ie: Plasma) instead of the client. There will be apps using libnotify or any other lib that can set their timeouts. The reason I added this is because in KDE Connect we show notifications when there is an incoming "pair request", and I wanted to make the notification stay there for as long as the request is valid. Since the notification is the only way to accept the pair request, I think it results in a bad user experience if the notification disappears before the user can act on it. There is an alternative solution to my use case: making the notification persistent and manually dismissing it when the request is no longer valid, but I've decided to not implement it this way because some notification servers don't support persistent notifications (eg: Ubuntu Unity). What do you think? REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
[Differential] [Commented On] D4663: Allow setting the timeout value.
mck182 added a comment. This was discussed couple times before and the reason this was never added is because of potential misuse of this by setting extremely high value, making the bubble virtually sticked to your screen forever. This should be handled by the server that should do the right thing(tm) like eg. Plasma does a word count and then with simple heuristic determines the display time. Regardless of Plasma however, the server should always have a sensible default that all apps should follow, therefore this option was never added and I still think it shouldn't be there today; I can't see a reason why would you want the bubble to be displayed for either very short time or very long time. For anything in between the server default should be good enough. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: mck182, #frameworks
