2014-08-14 21:05 GMT+02:00 Marco Martin <notm...@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/ _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
