<table><tr><td style="">davidedmundson requested changes to this revision.<br />davidedmundson added a comment.<br />This revision now requires changes to proceed.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D26338">View Revision</a></tr></table><br /><div><div><p>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?<br />
If it does need that code anyway, there's no point doing fixes in startkde</p>

<hr class="remarkup-hr" />

<p>Code wise, this gives a timeout for anyone who doesn't run kwin composited, which would be a problem as is.</p>

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

<p>I've been wanting to move the kwin startup from ksmserver into startkde anyway, doing those things together would make the most sense.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D26338">https://phabricator.kde.org/D26338</a></div></div><br /><div><strong>To: </strong>esjeon, Plasma, davidedmundson<br /><strong>Cc: </strong>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<br /></div>