[Differential] [Commented On] D4663: Allow setting the timeout value.

Martin Klapetek noreply at phabricator.kde.org
Wed Feb 22 02:36:55 UTC 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170222/599ec4f8/attachment.html>


More information about the Kde-frameworks-devel mailing list