<table><tr><td style="">mck182 added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4799" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ol class="remarkup-list">
<li class="remarkup-list-item">A quick check if KSplashQML is found in the processes list (afaics, there's no alternatives to ksplash)</li>
<li class="remarkup-list-item">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</li>
</ol></blockquote>

<p>The problem with these and practically any kind of<br />
checking for KSplash *from* KNotifications is that<br />
it is the wrong "direction", so to speak. The reason<br />
being that KSplash runs for about 5 seconds on<br />
average and only during the system startup. Any<br />
check for KSplash in KNotification adds a performance<br />
penalty to every single application using it and that's<br />
only because of those ~5 secs during startup. Therefore<br />
the solution should be different and/or at different<br />
place altogether.</p>

<p>Another consideration is apps running in non-Plasma<br />
sessions; this is after all just a problem of Plasma, which<br />
makes me even more convinced that the solution shouldn't<br />
be in KNotification but rather in KSplash/Plasma.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ol class="remarkup-list" start="2">
<li class="remarkup-list-item">KSplash could listen for registration of a new dbus instance of KNotifications and emit a message to it (most probably too slow)</li>
</ol></blockquote>

<p>I'm not sure I understand this one.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ol class="remarkup-list" start="4">
<li class="remarkup-list-item">Any other way to check whether the start-up process is still running without relying on KSplash?</li>
</ol></blockquote>

<p>As noted above, I think this whole logic should go<br />
elsewhere, ideally.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>On a sidenote, I saw a couple comments about a 'new kde start system', but nothing more informative. Got any info?<br />
 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.</p></blockquote>

<p>I have no idea about that, sorry. Try emailing<br />
plasma-devel@kde.org and ask there. Also check the<br />
git blame on that line, if it's more than 18 months old<br />
commit, there are most likely no plans at all.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>That would add a lot of overhead & complexity to KSplash itself for a small case, I wouldn't like it.</p></blockquote>

<p>Actually, it's not at all that bad. Assuming we're talking<br />
only about collecting them and then reemitting them<br />
once KSplash is done, this would be dead simple. If<br />
that's a good/proper solution I can't tell.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R289 KNotifications</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4799" rel="noreferrer">https://phabricator.kde.org/D4799</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>vpilo<br /><strong>Cc: </strong>mck182, Frameworks<br /></div>