D26338: Ensure WM initializes before session starts
Eon S. Jeon
noreply at phabricator.kde.org
Tue Jan 7 04:51:09 GMT 2020
esjeon added a comment.
In D26338#588960 <https://phabricator.kde.org/D26338#588960>, @davidedmundson wrote:
> On the conceptual level, does it make more sense for the relevant client (konsole) to monitor for compositing changed itself. It's something that could change at runtime regardless, so it needs to react to it anyway?
> If it does need that code anyway, there's no point doing fixes in startkde
Technically, yes, apps can do that. But this will force changes to any apps that embed Konsole (i.e. dolphin, kate) or depend on desktop effects. Also, this issue will arise whenever an app implements such features. We can just solve this here and forget about it forever.
Also, the problem only occurs during session restoration, so it's clear that one change here can fix for all applications.
> Code wise, this gives a timeout for anyone who doesn't run kwin composited, which would be a problem as is.
Welp, I agree, but there's just no way to figure out if user wants compositor or just WM. A possible solution is to make this toggleable through configuration or env, which isn't exactly beautiful.
Still, the impact can be minimized by moving `wmjob` to right before session restoration instead of stage0.
> also I don't like the split that ksmserver is waiting for kwin to register on ICE, and startkde is waiting on kwin through a combo of both DBus and X atoms in KWindowSystem::compositingActive(). That's 3 different paths all used at once.
>
> I've been wanting to move the kwin startup from ksmserver into startkde anyway, doing those things together would make the most sense.
I agree. Things will be much cleaner if WM is handled in startkde. WM isn't really a part of session, and ksmserver already treats WM as a special case anyway.
REPOSITORY
R120 Plasma Workspace
REVISION DETAIL
https://phabricator.kde.org/D26338
To: esjeon, #plasma, davidedmundson
Cc: asturmlechner, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200107/9773e73d/attachment.html>
More information about the Plasma-devel
mailing list