[Differential] [Commented On] D4799: Delay notifications until desktop session has loaded

[Martin Klapetek]

mck182 added a comment.


  > 1. A quick check if KSplashQML is found in the processes list (afaics, there's no alternatives to ksplash)
  > 2. KNotifications could send an async call to KSplash with a very quick timeout and start deciding on its queued notifications if/after the answer arrives
  
  The problem with these and practically any kind of
  checking for KSplash *from* KNotifications is that
  it is the wrong "direction", so to speak. The reason
  being that KSplash runs for about 5 seconds on
  average and only during the system startup. Any
  check for KSplash in KNotification adds a performance
  penalty to every single application using it and that's
  only because of those ~5 secs during startup. Therefore
  the solution should be different and/or at different
  place altogether.
  
  Another consideration is apps running in non-Plasma
  sessions; this is after all just a problem of Plasma, which
  makes me even more convinced that the solution shouldn't
  be in KNotification but rather in KSplash/Plasma.
  
  > 2. KSplash could listen for registration of a new dbus instance of KNotifications and emit a message to it (most probably too slow)
  
  I'm not sure I understand this one.
  
  > 4. Any other way to check whether the start-up process is still running without relying on KSplash?
  
  As noted above, I think this whole logic should go
  elsewhere, ideally.
  
  > On a sidenote, I saw a couple comments about a 'new kde start system', but nothing more informative. Got any info?
  >  e.g. kded/src/kded.cpp at 770, before calling on dbus KSplash.setStage(): //NOTE: We are going to change how KDE starts and this certanly doesn't fit on the new design.
  
  I have no idea about that, sorry. Try emailing
  plasma-devel at kde.org and ask there. Also check the
  git blame on that line, if it's more than 18 months old
  commit, there are most likely no plans at all.
  
  > That would add a lot of overhead & complexity to KSplash itself for a small case, I wouldn't like it.
  
  Actually, it's not at all that bad. Assuming we're talking
  only about collecting them and then reemitting them
  once KSplash is done, this would be dead simple. If
  that's a good/proper solution I can't tell.

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D4799

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: vpilo
Cc: mck182, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170226/97d97639/attachment.html>