mart added inline comments.

INLINE COMMENTS

> romangg wrote in org_kde_plasma_virtual_desktop.xml:45
> This event is redundant with the current implementation. A client can infer 
> the number of rows and columns from the org_kde_plasma_virtual_desktop 
> objects it receives and their maximum row and column values.
> 
> Also a compositor might be interested in setting a custom layout like this: 5 
> virtual desktops as a cross (one top, 3 in a row mid, one bottom). While one 
> can still say this has in some sense 3 rows and 3 columns, the event in this 
> case loses its intended meaning of defining the "layout".
> 
> Look at my review comment for a different approach.

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)

> romangg wrote in plasma-window-management.xml:273
> Just name it `enter_virtual_desktop` I would say. For 
> `request_leave_virtual_desktop` the same.

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?

> romangg wrote in plasmavirtualdesktop_interface.h:77
> The compositor does not need to decide upon an id. Let KWayland do this 
> internally (this also means that whenever `createDesktop` is called it is 
> guaranteed that a new PlasmaVirtualDesktopInterface will be returned.
> 
> Or is this needed in regards to Activities down the road? If yes I would also 
> argue that a KWayland internal id would be nicer and KWin should map them 
> then to Activity ids.

what i would like to is to have in the end the ids coming from kactivities, (as 
i want in wayland desktops===activities) which makes more sense to link and use 
in kwin, rather than in kwayland

> romangg wrote in plasmavirtualdesktop_interface.h:103
> That the management class is friend to the things it manages (here the 
> PlasmaVirtualDesktopInterface) ok, but the other way around... I would maybe 
> try to work without it.

yeah, i would need to make things work without needing that ugly ordereddesktops

REPOSITORY
  R127 KWayland

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

To: mart, #kwin, #plasma, graesslin, hein
Cc: romangg, kde-frameworks-devel, michaelh, ngraham, bruns

Reply via email to