D12820: Add KWayland virtual desktop protocol

[Roman Gilg]

romangg added inline comments.

INLINE COMMENTS

> mart wrote in org_kde_plasma_virtual_desktop.xml:45
> isn't better the layout to be communicated by the manager? the reasoning was to have it loosely map on models.
> the model tells how many rows it has, then the single item on what row it is located.
> 
> Also, I think is to be decided now as it influences everything else:
> Do we want to allow "holes" in the order? (as you said one in first row, 3 in second etc)

> isn't better the layout to be communicated by the manager?

In the review comment with the "different approach" I propose exactly this. I.e. not remove this (currently redundant) event `layout`, 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.

> the reasoning was to have it loosely map on models.
>  the model tells how many rows it has, then the single item on what row it is located.

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 `layout` event first emitted or the `layout_position` events for the remaining VDs? How in both cases should the client react?

If the client first receives the `layout` event it still does not really know which VD has been removed. If it first receives all `layout_position` events plus the `removed` event it does not need the `layout` event any more.

But in any case the client would need to hold the VDs with already received `layout_position` 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.

> Do we want to allow "holes" in the order? (as you said one in first row, 3 in second etc)

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.

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.

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.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D12820

To: mart, #kwin, #plasma, graesslin, hein
Cc: bshah, romangg, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180514/19908666/attachment.html>