When running krusader in root mode the first time a dialogue box is shown it contains no text and is transparent, as in this screenshot. (Confirmation of File Delete)
http://paste.opensuse.org/d87cc556
After approx 25 secs the text appears, subsequent dialogue boxes are normal.
If krusader is closed and reopened then again the first time a dialogue box is shown there is the same 25 sec delay.
Running krusader with ordinary user rights the dialogue box is shown normally.
Tumbleweed 20170610
krusader 2.6.0-1.2
Plasma 5.10.1
KDE Frameworks 5.34.0
Qt 5.7.1
There have been no changes to this system apart from snapshot updates. (zypper dup --no-allow-vendor-change)
The problem arose sometime within the last few snapshots, unable to be more precise.
I can confirm that on Leap 42.2.
The 25s very much sound like a DBUS timeout.
Hm, maybe we just should drop “root mode” like upstream did (I “patched” it back in)… 
PS: dolphin super-user mode has the same problem. So it seems to be something more general, not specific to krusader. Maybe a change in KDE Frameworks? (knotifications)
Thanks, I was wondering if it was a “just me”.
Hm, maybe we just should drop “root mode” like upstream did (I “patched” it back in)… :P)
That would be rather a blow to my working routines… 
krusader is my favoured file manager for all things “root”.
Well, at least currently you could still run krusader via kdesu, unlike dolphin (but we patched dolphin in openSUSE to still allow that too).
Of course you would have the same problem, as that’s what the “root mode” menu entry does anyway.
I already found the “culprit” though: it’s /usr/share/dbus-1/services/org.kde.plasma.Notifications.service, if you remove that, the delay is gone.
Not sure that’s (easily) fixable, but I do remember upstream bug reports about such 25s delays caused by it (for applications running as user, IIANM).
What other, if any, side effects may that removal have? For the moment I’ll live with the delay, it’s not as though I’m using root mode a lot.
The purpose of this service is to avoid losing notifications during login, when Plasma (and it’s notification service) have not been started yet.
It basically “catches” the notification and waits for the actual notifications service to show up (with a timeout of 25s).
https://phabricator.kde.org/R120:5bf889f7b94b388b71a357fe2e9517b1ca3bbbdc
So, this problem will always happen when there is no notification service running, I think.
In this particular case, the user’s desktop’s notification service is not seen as the application runs as root.
But it would also happen if you run the application as user in a desktop that doesn’t have a notification service (like IceWM e.g.), IIANM.
OK - Thanks for that explanation. 
I’ll temporarily remove the service and see what, if any, impact it has with the way this system is used. I can’t offhand think of any notifications during login.
Thanks for the link.
For the moment I’ve removed the service and it doesn’t appear to have any adverse impact in my own use case.
That’s to be expected.
After all, it’s new in 5.10.0 and didn’t exist before. 
As I understand it now, the main purpose actually is to delay notifications during login so that they don’t appear on top of the splash screen.
There’s a corresponding change in knotifications 5.33 btw (unconditionally start the notifications service despite of the desktop in use), which plays a part here too:
https://cgit.kde.org/knotifications.git/commit/?id=2d40672b0c8569329df78f77c425e9989e68c037Before, this was only done when running inside a full KDE session, and it triggers the start of /usr/share/dbus-1/services/org.kde.plasma.Notifications.service which waits upto 25s for the actual notification service to appear (which of course only makes sense during login to a KDE session).
Yes, that’s similar to what you wrote back in post #6 of this thread. I’ve never (yet) had a notification appear over the splash screen, and it wouldn’t particularly worry me if it did… lol!
@wolfi323
Just updated TW to 20170702 and was expecting to have to delete “org.kde.plasma.Notifications.service” again as “plasma5-workspace” was amongst the updates…
but you’ve beaten me to it …
Yes, I removed the file from the package until this problem is fixed…
It also happens if you run KDE applications via ssh, not only as root or an a different desktop.