Feedback on xdg-shell from Plasma crew

[Martin Gräßlin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141215/cb2bcbd9/attachment.sig>