<table><tr><td style="">romangg added inline comments.
</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/D12820">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D12820#inline-66164">View Inline</a><span style="color: #4b4d51; font-weight: bold;">mart</span> wrote in <span style="color: #4b4d51; font-weight: bold;">org_kde_plasma_virtual_desktop.xml:45</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">isn't better the layout to be communicated by the manager? the reasoning was to have it loosely map on models.<br />
the model tells how many rows it has, then the single item on what row it is located.</p>

<p style="padding: 0; margin: 8px;">Also, I think is to be decided now as it influences everything else:<br />
Do we want to allow "holes" in the order? (as you said one in first row, 3 in second etc)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p style="padding: 0; margin: 8px;">isn't better the layout to be communicated by the manager?</p></blockquote>

<p style="padding: 0; margin: 8px;">In the review comment with the "different approach" I propose exactly this. I.e. not remove this (currently redundant) event <tt style="background: #ebebeb; font-size: 13px;">layout</tt>, but even promote it by not only sending the current row and column count, but also directly all positions of existing VDs through a wl_array.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p style="padding: 0; margin: 8px;">the reasoning was to have it loosely map on models.<br />
 the model tells how many rows it has, then the single item on what row it is located.</p></blockquote>

<p style="padding: 0; margin: 8px;">Thanks, good to know the idea behind it. I see mostly a problem with synchronization between the single virtual desktop objects among themselves as well as with the manager with this approach. For example if the compositor decides to remove a virtual desktop, what reduces the row/column count: Is the <tt style="background: #ebebeb; font-size: 13px;">layout</tt> event first emitted or the <tt style="background: #ebebeb; font-size: 13px;">layout_position</tt> events for the remaining VDs? How in both cases should the client react?</p>

<p style="padding: 0; margin: 8px;">If the client first receives the <tt style="background: #ebebeb; font-size: 13px;">layout</tt> event it still does not really know which VD has been removed. If it first receives all <tt style="background: #ebebeb; font-size: 13px;">layout_position</tt> events plus the <tt style="background: #ebebeb; font-size: 13px;">removed</tt> event it does not need the <tt style="background: #ebebeb; font-size: 13px;">layout</tt> event any more.</p>

<p style="padding: 0; margin: 8px;">But in any case the client would need to hold the VDs with already received <tt style="background: #ebebeb; font-size: 13px;">layout_position</tt> events in some intermediate state until it has received the events for all VDs plus the removed event for the VD, which got removed. Otherwise it might put multiple VDs on the same position.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p style="padding: 0; margin: 8px;">Do we want to allow "holes" in the order? (as you said one in first row, 3 in second etc)</p></blockquote>

<p style="padding: 0; margin: 8px;">For this protocol extension I would vote in favor of that, because there are valid use cases and we should write our protocols directly for a larger audience if possible. Here if we use a matrix for representation (with 0 if there is a hole) it wouldn't introduce much more complexity.</p>

<p style="padding: 0; margin: 8px;">Currently on X we only allow full rows and columns I believe, so the protocol implementation in KWin / Plasma could still only use full rows / columns for now.</p>

<p style="padding: 0; margin: 8px;">In general in the long run I imagine a KCM, where a user sees the current VDs in an overview like with the pager and then has buttons around it with plus signs on it the user can click to add another VD in this location. Also with this approach we could later on add "spans" over multiple columns/rows. For example a main VD and below three auxiliary VDs.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R127 KWayland</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12820">https://phabricator.kde.org/D12820</a></div></div><br /><div><strong>To: </strong>mart, KWin, Plasma, graesslin, hein<br /><strong>Cc: </strong>bshah, romangg, kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>