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

In 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.

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

I would say it is enough to just make plasma grab the interface early enough. It would result in the popups not show.

We don't need to show those notifications. It is a bug in ksplash that the popups are visible at all.

Another alternative could be to bind the checks suggested here to the env variable KDE_FULL_SESSION to make it at least a plasma only penalty

@graesslin I disagree. Some popups might be useful, some are very useful; we should aim to never drop any. Just as an example, the popup with the Yakuake console toggle key is pretty fundamental to be reminded of, the first few times you start it up.

It's all about saving users from annoyances. Papercuts, in Canonical terms.

@mck182 - I think your approach of taking them in, and replaying them at the end, is the best option I can see from my inexperienced POV.

It is a bug in ksplash that the popups are visible at all.

Fallback for KNotification is a KPassivePopup which is unredirect I think? Ksplash, in contrast to the splash screen, doesn't continuously re-raise itself and KWin doesn't do anything special to it either. (apart from some special cases in various effects)

Some popups might be useful, some are very useful

Most are not, however. PowerDevil, for instance, actually delays its notifications (e.g. you startup with a low battery) until a notification service registers itself to avoid the embarrassing popup ontop of KSplash while still showing the notification soon after logging in. Almost anything else ("You are now connected to network X") is pointless, and I hate this Yakuake notification when logging in.

About the code in kded that calls ksplash: that code is obsolete and currently only kept for compatibility reasons, see https://git.reviewboard.kde.org/r/129010/
IOW you can ignore that code completely.

In D4799#90169, @dfaure wrote:

About the code in kded that calls ksplash: that code is obsolete and currently only kept for compatibility reasons, see https://git.reviewboard.kde.org/r/129010/
IOW you can ignore that code completely.

OK, thanks :)

In D4799#90165, @broulik wrote:

Most are not, however. PowerDevil, for instance, actually delays its notifications (e.g. you startup with a low battery) until a notification service registers itself to avoid the embarrassing popup ontop of KSplash while still showing the notification soon after logging in. Almost anything else ("You are now connected to network X") is pointless, and I hate this Yakuake notification when logging in.

All notifications can be disabled if the user finds them useless and/or annoying - not a reason to prevent them from showing at all by means of frameworks, though, IMHO. And we can't expect the applications to all do what PowerDevil does. Unless we make this change happen (with another trigger to decide whether the splash is being shown).

@mck182 I didn't notice before, but KNotifications is already making blocking calls on creation:

src/notifybypopup.cpp@182:
    QDBusConnectionInterface *interface = QDBusConnection::sessionBus().interface();
    d->dbusServiceExists = interface && interface->isServiceRegistered(dbusServiceName);

And there's more.
I can make the KSplash notification relay; but I wouldn't know how to get rid of those..

Yes interface->isServiceRegistered(dbusServiceName) is technically blocking, but it can't block for a long time, since it's only talking to the dbus daemon. The reply comes in rather quickly, unlike a blocking call to another KDE process which could be busy or where the call itself could take a long time to be processed.
In summary, I don't think an existing call to isServiceRegistered can be used as an argument for making (potentially much much longer) blocking calls.

In D4799#91109, @dfaure wrote:

Yes interface->isServiceRegistered(dbusServiceName) is technically blocking, but it can't block for a long time, since it's only talking to the dbus daemon. The reply comes in rather quickly, unlike a blocking call to another KDE process which could be busy or where the call itself could take a long time to be processed.
In summary, I don't think an existing call to isServiceRegistered can be used as an argument for making (potentially much much longer) blocking calls.

Not trying to :) I was just concerned about those pre-existing calls. If those are fine, I'll just go on with my plan.

There is another solution that would work without any changes to KNotification.

DBus has a solution to buffer messages and wait for a name to become available, it happens in DBus activation. If plasmashell was DBus activated on org.freedesktop.Notifications we wouldn't have this problem at all.

Making plasmashell do that is probably a bit weird, but there is a hack we can do that I've seen done in Telepathy. Instead of activating plasmashell we have a small binary that gets DBus activated but simply idles waits for org.freedesktop.Notifications to become available then quits.

DBus-daemon thinks it's launched something and happily waits for the name to become available queuing the messages. Knotification can just fire and forget as normal.
The only time there's any performance penalty is if you do send a notification pre-plasmashell starting up, and it's quite minor.

I've tested this using, https://paste.kde.org/pwdqvevvo
running "notify-send foobar"
then waiting 10 seconds and starting plasmashell
Notification appeared perfectly.

We'd need to re-implement mc-wait-for-name in Plasma code (or just use Exec=sleep 30)

In D4799#91246, @davidedmundson wrote:

There is another solution that would work without any changes to KNotification.

DBus has a solution to buffer messages and wait for a name to become available, it happens in DBus activation. If plasmashell was DBus activated on org.freedesktop.Notifications we wouldn't have this problem at all.

Making plasmashell do that is probably a bit weird, but there is a hack we can do that I've seen done in Telepathy. Instead of activating plasmashell we have a small binary that gets DBus activated but simply idles waits for org.freedesktop.Notifications to become available then quits.

DBus-daemon thinks it's launched something and happily waits for the name to become available queuing the messages. Knotification can just fire and forget as normal.
The only time there's any performance penalty is if you do send a notification pre-plasmashell starting up, and it's quite minor.

I've tested this using, https://paste.kde.org/pwdqvevvo
running "notify-send foobar"
then waiting 10 seconds and starting plasmashell

Notification appeared perfectly.

We'd need to re-implement mc-wait-for-name in Plasma code (or just use Exec=sleep 30)

This sounds like a very good alternative to me. I can implement it in KSplash.

Cool, but we should put the blocking code in plasma, not here. Otherwise we'd interefere with other platforms.
Maybe in plasma-workspace/startkde

Looks like this could work. The KDE_FULL_SESSION check is
really old, I'm not sure if this has any implications.

As David noted, the waiting thing should go to Plasma workspace,
that's where it belongs. Also, it would be preferred if the implementation
was properly split into main.cpp and your class .h and .cpp

I pushed D5012; this rev is now testable.

Ping

[my excuses if it's not good practice to do so]

This introduces a regression https://bugs.kde.org/show_bug.cgi?id=380974