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

Valerio Pilo noreply at phabricator.kde.org
Sun Feb 26 00:29:50 UTC 2017


vpilo added a comment.


  In https://phabricator.kde.org/D4799#89931, @mck182 wrote:
  
  > Thanks for the patch! I wanted to do exactly this a long
  >  time ago. However this solution brings a burden to all
  >  apps using KNotification in form of a blocking dbus call
  >  which is further only relevant when used in Plasma.
  >
  > That's a no-no I'm afraid, we'd have to find a better solution.
  
  
  I understand. I'm out of the KDE development loop since a few years, so I wouldn't know what alternatives might there be that will be acceptable in the frameworks.
  Straight away I am thinking about:
  
  1. A quick check if KSplashQML is found in the processes list (afaics, there's no alternatives to ksplash)
  2. KSplash could listen for registration of a new dbus instance of KNotifications and emit a message to it (most probably too slow)
  3. 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
  4. Any other way to check whether the start-up process is still running without relying on KSplash?
  
  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 was thinking that maybe KSplash should have the notifications
  >  dbus interface instead and handle it somehow on its own,
  >  either just collecting the notifications and then reemitting them
  >  once it's done splashing, or just displaying them directly, I dunno.
  
  That would add a lot of overhead & complexity to KSplash itself for a small case, I wouldn't like it.

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/35c87775/attachment.html>


More information about the Kde-frameworks-devel mailing list