<table><tr><td style="">luebking added a comment.
</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/D7521" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>There's a major pitfall to inter-process modality:<br />
In case of a persistent transient (used by several clients), the leader may loose the focus access "forever" (because the modal window remains)</p>

<p>Thus and in general, transients should certainly not be unconditionally modal, but the ability to control this attribute to the WM will be useful.<br />
If client A crucially relies on input in client B to proceed, it will typically reject internal focus distribution and input handling.</p>

<p>This is complex enough if the client spawns a nested event loop and tries to pass the focus on to the foreign window, but in a multi-process case, client A might simply block for the I/O to gain this behavior.<br />
In this case a "dead" window might receive the input focus.</p>

<p>Also the modality controls the forced visibility of the transient along the leader.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7521" rel="noreferrer">https://phabricator.kde.org/D7521</a></div></div><br /><div><strong>To: </strong>mart, Plasma, graesslin<br /><strong>Cc: </strong>luebking, graesslin, davidedmundson, plasma-devel, kwin, KWin, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, lukas<br /></div>