<div dir="ltr"><div>Hi Martin!<br></div><div>First off, thanks for looking at it and giving your thoughs.  I'm going to reply to a few things below from a sort-of "general wayland perspective"  I'll leave the hashing out of details to the people who actually work on real compositors.  Hopefully, the rest of the list shows similar restraint *sigh*.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 5:30 AM, Martin Gräßlin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I had a look at the xdg-shell proposal in weston (see [1]) and want to provide<br>
some feedback from a Plasma/KWin point of view.<br>
<br>
First of all: thanks for the work so far on the xdg-shell. The work looks<br>
quite good and promising. If you reply to the thread, please keep both the<br>
plasma and wayland mailing list on CC: not all domain experts from Plasma are<br>
on the wayland mailing list and I don't want to play proxy with my peer<br>
developers ;-)<br></blockquote><div> <br></div><div>Done.  Hopefully, not being a member of that list won't be a problem.  I know they'll have to subscribe to the wayland list in order to be able to write to it.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm grouping the feedback by some categories.<br>
<br>
Decorations<br>
---------------<br>
<br>
My understanding is that xdg-shell surfaces are supposed to do client-side-<br>
decorations. If that is the case I consider the protocol as not yet sufficient<br>
for our needs. It would render huge regressions as several features are no<br>
longer possible. This includes:<br>
* putting windows on all desktops<br>
* putting a window to a keep above/keep below layer<br>
* shading windows (personally I don't mind if that goes away)<br>
<br>
For those three we have dedicated decoration buttons which can be globally<br>
configured. We would like to still be able to provide them.<br></blockquote><div><br></div><div>It seems a bit odd to me that those are common enough to need to be single-click.  That said, it's still a regression if you can't do it.  At some point in the past, xdg_shell had a way for clients to request these states.  Then, for the sake of better separation (they're not really client things), they were moved into the compositor-handled context menu.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In addition there are quite some interaction limitations:<br>
* configurable mouse actions: a right click might not trigger a context menu,<br>
mouse wheel support<br></blockquote><div><br></div><div>It doesn't have to.  The client can use whatever button or key it wants to use to trigger the context menu.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* multiple and configurable mode on the maximize button: KWin allows to<br>
maximize horizontally/vertically and fully depending which mouse button was<br>
used on the maximize button<br></blockquote><div><br></div><div>Yes, these are not modes that most other compositors have/support.  They could be plasma-specific states.  However, I immagine you'd like to be able to do that to firefox and other non-KDE apps.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also for integration with the desktop environment I see problems:<br>
* how to specify the button order? We don't want apps to do things like Opera<br>
did: putting the buttons on the wrong side ;-)<br></blockquote><div><br></div><div>Not much you can do about that in some ways.  Then again, maybe Opera is annoyed that you keep moving their buttons. ;-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* specifying a drag delay to trigger move/resize (or better pass this into the<br>
compositor?)<br>
<br>
In general I fear that in the current state it would render a for us rather<br>
unsuitable system exposing the same problems as GTK's CSD in the X11 world.<br></blockquote><div><br></div><div>Ah, CSD, the age-old argument...  I really hope we can avoid an all-out war on this.  A few comments in general.<br><br></div><div>First off, If we want windows to be decorated, we have to pick one of either the client or the server, that is required to support decorations.  In Wayland, the choice has been made that clients always have to be able to decorate.  That doesn't mean that WM's never can, but someone has to, and that someone is clients.  I really don't think that's going to change, so let's just avoid debating it.<br><br></div><div>That said, We could come up with some sort of negotiation.  I think the preference for the moment (of myself and Kristian; can't speak for anyone else) would be to initially do this as its own extension which would be advertised by kwin and clients would support.  We could eventually make it mainline, but let's get it working first.<br><br></div><div>One note about said extensions is the question of "who wins?"  KWin wants to decorate windows.  GNOME apps want to do it themselves and frequently have reworked interfaces around it.  Do we force them to be server-side or does KWin budge and let them be client-side?  That's a question that I don't think will be easy to answer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Convergence<br>
----------------<br>
<br>
One of our convergence features is that we adjust the window controls. E.g.<br>
* on Active/Touch no window has controls<br>
* on Netbook only dialogs have controls, while all other windows have no<br>
controls<br>
* On Desktop the user is allowed to decide per window whether a window should<br>
have controls<br>
<br>
I'm not completely sure on how to provide this. I'd say that this should be<br>
another state to tell the surface whether it should render controls. Also the<br>
client should tell whether it's currently rendering controls to prevent that a<br>
desktop shell exposes further controls for a client using own controls.<br></blockquote><div><br></div><div>Could you please define the term "controls".  Maybe that's a common term, but I'm not familiar with it, so it would be good to have a definition.<br><br></div><div>As far as how to do it goes, the simplest option would probably be to have a state for it.  You can claim a namespace of states for plasma and we'll add that to the spec.  One thing we're missing currently, is a set_state request so that clients can request a particular state.  We have explicit set_* requests for the core states, but no good way for a client to request an extension state.  We're also missing any sort of way for clients to say which extension states they support.  Jasper, how are you doing this in GNOME?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
General Comments<br>
------------------------<br>
<br>
* set_app_id: What's meant with "It should be the ID that appears in the new<br>
desktop entry specification, the interface name."? Especially what's the "new<br>
desktop entry specification"?<br>
<br>
* set_window_geometry: this looks like an insufficient solution to us. Drop<br>
shadows should not be part of the window. In KWin/Plasma we have shadows in a<br>
dedicated buffer which can get highly compressed and doesn't require to have<br>
complicated logics to map the windows. Supporting this creates problems for<br>
things like thumbnails where we want to exclude shadows to be able to produce<br>
higher quality thumbnails. Also of course snapping and etc.<br>
<br>
* why a specific unset_maximized request? Wouldn't it be better to just have<br>
one maximized request with enum values (maximized horizontally, maximized<br>
vertically, maximized fully, restored?)<br>
<br>
* for all state changes like set_maximized or set_fullscreen I suggest to add<br>
the serial which triggered the change. By that I'm assuming that a surface is<br>
only allowed to change state when a user interacted with the window.<br>
<br>
* icon? For the task manager we need a way to get an icon. This could be<br>
either a surface (e.g. allow animated icons) or just a name of the icon theme<br>
item. We have many applications changing the icon while interacting (e.g. a<br>
chat application indicating that the remote is typing) and thus a general icon<br>
is not sufficient.<br></blockquote><div><br></div><div>I think the way GNOME does it (guessing here, not a mutter dev) is pulling a static icon from the .desktop file.  They have other ways of handling notifications that don't involve the icon.  I did always think that not having an icon was odd though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* show_window_menu: it's lacking some of the feedback we gathered on the NETWM<br>
mailing list. E.g. if it's from a menu button it should provide the geometry<br>
of the button to provide a good interaction<br>
<br>
* set_parent: what is the use case? Is that supposed to be a dialog? If yes:<br>
why is it restricting on how a desktop environment is supposed to handle them?<br>
<br>
* what about semantic window types: we would like to know what a surface is.<br>
Is it a dialog? Is it a tooltip, etc. etc. I think this is one of the strong<br>
points of NETWM and completely missing here.<br>
<br>
* a mechanismn like startup notification/_NET_WM_USER_TIME: a compositor would<br>
probably want to know when a surface got created due to user interaction for<br>
focus stealing prevention<br></blockquote><div><br></div><div>There has been a big of discussion on this and no real conclusion yet.  Part of the problem here is that a timestamp is so easy to fake that it becomes almost useless.  In the world of "we're all adults here", it may work ok, but it's not foolproof.  If the application gets launched from a KDE launcher, you can fairly easily do a handoff from launcher to compositor and that would work fine.  When it comes to one app starting another, it's a bit more difficult to get right.<br><br>One option that has been discussed briefly would be to have some sort of a token that an app can hand to another app when it's launched that it then hands to the compositor to do some sort of handoff.  The compositor would then know what event (button press etc.) caused the app to launch and could use that.  It would also be usable for one app to hand some sort of privileges to another.  Unfortunately, that's never really been explored that thoroughly.<br><br></div><div>I've intentionally; left a lot of questions alone.  I'm not a mutter dev and, apart from discussions on the ML and some work on Weston, not really a window manager developer.  Hopefully, Jasper and the other mutter devs can fill you in on some of the details I don't understand as well and hopefully we can get some good discussion going.<br></div><div>--Jason<br></div></div></div></div>