2014-08-15 7:35 GMT+02:00 Martin Gräßlin <mgraess...@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/ _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
