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@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
