Hi all, I had a look at the xdg-shell proposal in weston (see [1]) and want to provide some feedback from a Plasma/KWin point of view.
First of all: thanks for the work so far on the xdg-shell. The work looks quite good and promising. If you reply to the thread, please keep both the plasma and wayland mailing list on CC: not all domain experts from Plasma are on the wayland mailing list and I don't want to play proxy with my peer developers ;-) I'm grouping the feedback by some categories. Decorations --------------- My understanding is that xdg-shell surfaces are supposed to do client-side- decorations. If that is the case I consider the protocol as not yet sufficient for our needs. It would render huge regressions as several features are no longer possible. This includes: * putting windows on all desktops * putting a window to a keep above/keep below layer * shading windows (personally I don't mind if that goes away) For those three we have dedicated decoration buttons which can be globally configured. We would like to still be able to provide them. In addition there are quite some interaction limitations: * configurable mouse actions: a right click might not trigger a context menu, mouse wheel support * multiple and configurable mode on the maximize button: KWin allows to maximize horizontally/vertically and fully depending which mouse button was used on the maximize button Also for integration with the desktop environment I see problems: * how to specify the button order? We don't want apps to do things like Opera did: putting the buttons on the wrong side ;-) * specifying a drag delay to trigger move/resize (or better pass this into the compositor?) In general I fear that in the current state it would render a for us rather unsuitable system exposing the same problems as GTK's CSD in the X11 world. Convergence ---------------- One of our convergence features is that we adjust the window controls. E.g. * on Active/Touch no window has controls * on Netbook only dialogs have controls, while all other windows have no controls * On Desktop the user is allowed to decide per window whether a window should have controls I'm not completely sure on how to provide this. I'd say that this should be another state to tell the surface whether it should render controls. Also the client should tell whether it's currently rendering controls to prevent that a desktop shell exposes further controls for a client using own controls. General Comments ------------------------ * set_app_id: What's meant with "It should be the ID that appears in the new desktop entry specification, the interface name."? Especially what's the "new desktop entry specification"? * set_window_geometry: this looks like an insufficient solution to us. Drop shadows should not be part of the window. In KWin/Plasma we have shadows in a dedicated buffer which can get highly compressed and doesn't require to have complicated logics to map the windows. Supporting this creates problems for things like thumbnails where we want to exclude shadows to be able to produce higher quality thumbnails. Also of course snapping and etc. * why a specific unset_maximized request? Wouldn't it be better to just have one maximized request with enum values (maximized horizontally, maximized vertically, maximized fully, restored?) * for all state changes like set_maximized or set_fullscreen I suggest to add the serial which triggered the change. By that I'm assuming that a surface is only allowed to change state when a user interacted with the window. * icon? For the task manager we need a way to get an icon. This could be either a surface (e.g. allow animated icons) or just a name of the icon theme item. We have many applications changing the icon while interacting (e.g. a chat application indicating that the remote is typing) and thus a general icon is not sufficient. * show_window_menu: it's lacking some of the feedback we gathered on the NETWM mailing list. E.g. if it's from a menu button it should provide the geometry of the button to provide a good interaction * set_parent: what is the use case? Is that supposed to be a dialog? If yes: why is it restricting on how a desktop environment is supposed to handle them? * what about semantic window types: we would like to know what a surface is. Is it a dialog? Is it a tooltip, etc. etc. I think this is one of the strong points of NETWM and completely missing here. * a mechanismn like startup notification/_NET_WM_USER_TIME: a compositor would probably want to know when a surface got created due to user interaction for focus stealing prevention Best Regards Martin Gräßlin [1] weston/protocol/xdg-shell.xml as of b502654b9fd9263964ccc4bdcbd8d633233b4f87
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
