D12820: Add KWayland virtual desktop protocol

[Roman Gilg]

romangg added a comment.


  How is a change of neighbors supposed to work for clients already bound to the proxy objects? For example consider virtual desktop grid:
  
    D1 D2
    D3 D4
  
  Compositor removes `D3` and let `D4` flow back to the left:
  
    D1 D2
    D4
  
  `desktop_removed` event is sent and for `D1` and `D2` bottom neighbor changes, for `D4` left and top neighbor change. To have a consistent state on the client at all time, one would need to tell the client when it has fully received all these information coming from multiple interfaces. Maybe it is enough to send the `done` event of the management interface not after itself has finished all events, but also every desktop interface has sent it. Not sure if this is fine protocol hygiene though. If it is we need to add it to the descriptions of the interfaces.

INLINE COMMENTS

> plasma-virtual-desktop.xml:25
> +        </description>
> +        <arg name="desktop" type="new_id" interface="org_kde_plasma_virtual_desktop"/>
> +        <arg name="id" type="string" summary="Unique id of the desktop"/>

This arg name should be `id` (judging from other example protocols). Find a different arg name for the second argument, for example `desktop_id` or just `desktop`. Together:

  <arg name="id" type="new_id" interface="org_kde_plasma_virtual_desktop"/>
  <arg name="desktop" type="string" summary="Unique identifier string of the desktop"/>

> mart wrote in plasma-window-management.xml:273
> tough is a thing the client asks for which may or may not be granted.. just enter_virtual_desktop looks like it's already decided?

It's a request, so it's intrinsic that it's not yet decided. You can say in the description, that the server might ignore this request, otherwise it sends the virtual_desktop_entered event.

REPOSITORY
  R127 KWayland

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

To: mart, #kwin, #plasma, graesslin, hein
Cc: zzag, 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/20180607/1cae7c0c/attachment.html>