https://bugs.kde.org/show_bug.cgi?id=362857
Eon S. Jeon <esj...@hyunmu.am> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esj...@hyunmu.am --- Comment #23 from Eon S. Jeon <esj...@hyunmu.am> --- (In reply to Christoph Feck from comment #17) > We do not want to delay restoring the session and wait until KWin is ready. > It is fine if applications are started before or during the window manager > startup. > > Konsole could use KWindowSystem::compositingChanged() to find out about the > current compositing state during runtime, and act accordingly. I do get that adding delay isn't a charming solution, but that doesn't mean solving this in other places is a valid option. Ad-hoc live detection is a source of complexity and race conditions, so app devs will straight reject implementing it, and tell their users to stop relying on this broken KDE feature. (e.g. https://github.com/tsujan/Kvantum/issues/341#issuecomment-461888167 ) Compositor is a *service* that a number of GUI apps depend on, so either its availability should be ensured before its dependents, or a stub has to be provided while the actual service is initializing. Both are what system service managers are doing, but neither is done in KDE, and the latter requires rather complicated changes. The only option is ensuring, and this can be achieved so easily by increasing a single delay value in startup logic (though different approach is preferable). I patched this on my laptop, and it runs flawlessly. If you're concerned about longer start-up time, it should be possible to cancel the delay by sending out feedback from KWin (or listening to KWin D-Bus signal). I'm trying this, though without any luck yet. -- You are receiving this mail because: You are watching all bug changes.