[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