Wayland protocols

[Pier Luigi]

2014-08-15 7:35 GMT+02:00 Martin Gräßlin <mgraesslin at kde.org>:
> On Thursday 14 August 2014 21:05:01 Marco Martin wrote:
>> 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 ;)
>>
>> * set_position
>> since often is needed to set position and size, maybe a set_geometry that
>> does all in one go?
>>
>> * set_grab_surface
>> just little clarification: "The surface set by this request will receive a
>> fake pointer" what exactly is its use case?
>>
>> * set_desktop_role/set_config_role etc
>> maybe set_surface_role(output, surface, enum role) ?
>>
>> * prepare_lock_surfaces: why a separate step from lock()?
>>
>> * quit: would that be equivalent to logging out?
>
> some more thoughts:
> * set_overlay_role: should we make the name more explicit:
> set_on_screen_display_role?

I like set_overlay_role (well the overlay enum value for
set_surface_role now), less verbose but still understandable.

> * concerning the lock/unlock: I would like to have the lock way better
> integrated in KWin. That is KWin should be responsible for locking and nobody
> else. My though is that KWin takes over the screen locker dbus interface and
> starts the screenlocker greeter  when it's needed. It could pass a dedicated
> fd to greeter and thus would know that it's the lock screen surface
> implicitly. That way we would not need a protocol at all and it's completely
> controlled by KWin.

How do you know its wl_surface?

Would be better to move lock/unlock to a separate .xml file and have
ksmserver handle that imho.
kwin or any other compositor would recognize the surface by its role then.

> * add_trusted_client: I kind of don't understand how that's supposed to work.
> Where's the fd coming from and how does the shell user know about it?

It's the fd of a socket to the Wayland server open by the client that
need to be trusted.

This comes from Weston having the screenshooter interface and a screenshot tool.
The idea was to forbid clients not in the whitelist to use that
interface and thus avoid malicious programs to capture your screen.
A shell would open the screenshooter program when it needs to do a
screenshot and add it to the whitelist.

This can probably go away although I don't know how ksnapshot will
work on Wayland.

> * quit: could you please elaborate why you think it's needed? I'd assume the
> server would get terminated by some higher level process once the session is
> torn down.
>
> Which processes do you intend to use this protocol? To me it looks like
> combining things from ksmserver and plasmashell.

quit might indeed be dropped since I bet ksmserver does proper session
management and quit what it is supposed to quit itself.

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