https://bugs.kde.org/show_bug.cgi?id=297068
--- Comment #5 from Lamarque V. Souza <lamar...@kde.org> --- (In reply to comment #4) > I'm not aware that (vanilla) kwin would launch the screenlocker - it's > actually handled by krunner (on "regular" KDE) You're right, kwin does not launch kscreenlocker (that was my misunderstanding). kscreenlocker is launched by dbus if anyone tries to access its services (auto-launch dbus feature). We use branch screenlocker from kde-workspace in Plasma Active, in that branch kscreenlocker was implemented as a standalone process and now I merged it into ksmserver. The kscreenlocker just locks the screen with a fully transparent window, there is another process (kscreenlocker_greeter) that draws the unlock dialog used in Plasma Active and that dialog is the one Thomas Pfeiffer is talking about. > What you observe would likely (for a very short time) rather be an outcome > of bug #158262 and by this fixed by https://git.reviewboard.kde.org/r/104519/ > (!warning! - that particular commit actually contains crash prone statements) > > A window being closed becomes (visually) raised above all other windows > (including the screenlocker) for the duration of it's closing animation (if > there's such) Well, in this case we really want the window to be above all others since the window in question is the unlock screen dialog. Preferrebly the dialog should stay there until the device is turned off but ksmserver closes the greeter right before closing kwin and itself afterwards, so for a short time there will be no unlock screen like Thomes described. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active