Wayland protocols

[Pier Luigi]

2014-08-14 21:05 GMT+02:00 Marco Martin <notmart at gmail.com>:
> On Thursday 14 August 2014, Pier Luigi wrote:
>> Hi,
>>
>> Just pushed some initial draft of the Wayland protocols on Github [1]
>>
>> I need people with knowledge of KF5 and plasmashell to comment it and
>> suggest improvements.
>
> just some quick comments after taking a quick glance at
> https://github.com/plfiorini/protocols/blob/master/shell.xml
>
> since i'm just getting into it now, those question are mostly to understand it
> better myself ;)

no problem :)

> * set_position
> since often is needed to set position and size, maybe a set_geometry that does
> all in one go?

it's the client (plasmashell for example) who resizes the surface, the
server (a compositor) may want to ask the client to resize the surface
though.
other protocols usually involve a configure event for that, i'm not
sure whether we need it.
one use case would be the desktop view: it is bound to the output size
and the compositor knows about them so it could ask the client to
resize the desktop view when the output mode changes.

> * set_grab_surface
> just little clarification: "The surface set by this request will receive a
> fake pointer" what exactly is its use case?

Change the mouse cursor shape when a window is grabbed and moved.

> * set_desktop_role/set_config_role etc
> maybe set_surface_role(output, surface, enum role) ?

Sounds good to me.

See: https://github.com/plfiorini/protocols/commit/f30be3d48e0600de0c7c191ff73e587658e7e424

I also think that calling set_desktop_role to move it to another
output is not good.
We probably need a set_output request which will do something
depending on the role: for the desktop role it will move the surface
to 0,0 in the output coordinates space.

The config role should probably be replaced by a more generic popup
interface or maybe set it to Qt::Popup and let the wayland QPA plugin
handle it as a popup.
If it is a popup it grabs the input and it is dismissed clicking outside.

Also, I added a notifications role since it is different than overlay:
https://github.com/plfiorini/protocols/commit/b72c7a87dded67a5ab24fdafb7fcf249549641f2

> * prepare_lock_surfaces: why a separate step from lock()?

because the client doesn't know when it's right to create the lock surfaces.
lock() instructs the compositor to lock down the session and when this
is done the compositor emits prepare_lock_surfaces event telling the
client to create the lock surfaces.

with locking down the session i mean hiding all surfaces, prevent
input for those surfaces and turning the screens off (or running the
screen saver if this is still a thing).

it is a separate step to avoid users seeing the lock surfaces but
prepare_lock_surfaces is sent soon enough so that when unlock() is
called the lock surfaces are ready.

If I understand plasmashell doesn't create the lock surfaces, but
ksmserver does.
It might be worth considering whether it can happen that for some
reason ksmserver fails to create the lock surfaces.

This wasn't an issue for Hawaii (since the lock surfaces were created
by the shell itself) but nevertheless it had a background surface, on
top of that the real desktop view.
The compositor only showed the background surface when lock() was
called, so at least a wallpaper was always visible.

> * quit: would that be equivalent to logging out?

it's a request the client sends to the server asking it to quit immediately.
maybe i got the logout sequence wrong, when plasmashell goes down it
should send this quit request to the compositor in order to terminate
it.
it is sent when the client is sure the session is going down
(applications were already asked to quit and they agreed) hence the
client doesn't need an event, it just assumes the server quits when
receives the request.

-- 
Out of the box experience
http://www.maui-project.org/