<div dir="ltr"><br><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
<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>
<br>
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>
* 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>
<br>
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>
* 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>Unfortunately, this is going to be a long and uninteresting battle, and it's more one of politics than anything else. I have my opinions on this, and I'm not impartial enough to let them not affect the specification. If you make specific proposals, complete with patches to the protocol XML, I'd be happy to review them. I don't work on Wayland or GNOME full-time anymore, and my personal time is not going to be spent fixing this.<br><br></div><div>Fundamentally, this is the result of two different world views about the design and purpose of decorations. None of this is new to you, but let's recap.<br><br></div><div>GNOME's view is that window decorations are a part of the application and part of the application's design space. This matches what most new applications are doing, on all platforms [0].<br><br></div><div>KDE's view is that window decorations are part of the OS, are standard across the board for all applications, and are infinitely tweakable and configurable. You could speak more on *why* things were designed this way, I obviously think this is insane.<br><br></div><div>I think it's going to be difficult, if not impossible, to reconcile and support these two different world views in one specification, and I've just been doing a bad job by ignoring the problem. I don't know what the solution is, but I think it's going to have to be decided by Pekka or Jason. We're both too biased to come up with something good for both. :)<br></div><div><br>[0] We all remember terrible WinAmp skins, and Chrome's use of the titlebar on Windows got some angry, but MS is starting to use the titlebar space more effectively on their own apps. Office and Visual Studio now have their own style, ignoring the OS titlebar entirely. Android now allows the application to customize and change the status bar along with the notifications bar and actions bar at the top and the bottom, which have traditionally been seen as the OS decorations. <a href="http://www.google.com/design/spec/style/color.html#color-ui-color-application">http://www.google.com/design/spec/style/color.html#color-ui-color-application</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>If "controls" means window decorations, my personal opinion is that an application should be aware of its environment, and adjust its look and feel to be responsive, which very well mean its window decorations. It could get this from an environment variable, Wayland extension, or DBus property. I'd say that can be a KDE-specific extension for its applications and is out of the scope for this specification.<br><br></div><div>GNOME wants to focus on the desktop use case, and I'm not well aware enough of the requirements for a tablet or netbook-style interface.<br><br>My only other thoughts for the topic is that xdg-shell is designed for windows that have decorations that can be dragged, resized, and maximized by the user. Tablet applications that are always full-screen are simpler to design, and it might be easier to use your own shell protocol for the tablet interface, but I'm not an expert in that area and you can make your own judgment call on that.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div><br></div><div>At the time of writing, the desktop-entry spec was recently updated with a new recommended naming convention for applications. [1]<br><br></div><div>The "app ID" is meant to be "org.example.FooViewer", without any ".desktop".<br><br></div><div>From this, we also assume a DBus bus name on the session bus, and an object path for action activation, along with other features people might add to org.freedesktop.Application [2]. The wording of this isn't great, and I have a branch containing a rewrite of the documentation in progress.<br></div><div><br>[1] <a href="http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#basic-format">http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#basic-format</a><br>[2] <a href="http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus">http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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></blockquote><div><br></div><div>What's insufficient about it? The whole point of set_window_geometry was to be able to specify coordinates for snapping. Perhaps the documentation is unclear, I can explain a bit about what the intended flow of it is if you want.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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?) </blockquote><div><br></div><div>I don't really feel happy with separate horizontal / vertical maximization. It's not a concept GNOME wants to support, and it becomes complicated in the details. If I have a window that's vertically maximized, what should happen when I click the "maximize" button or use the "maximize keybinding"? What icon should be shown in the title bar?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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></blockquote><div><br></div><div>Why can't my game start fullscreen, or my web browser start maximized?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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>The application icon can be pulled out of the .desktop file. Anything more complicated like notifications, overlays, or emblems over the window icon is out of scope for this specification. If you have more specific requirements, let me know.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote><div><br></div><div>I'd be fine with extending this. A patch would be welcome.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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></blockquote><div><br></div><div>There's a user concept of a "tree of windows" about the transients and their parents, which is unrelated to the actual X11 window tree. For instance, if I open a preferences dialog, that window is a transient of the toplevel it came from. This can be for dialogs, or it can be for GIMP-style MDI toolbox interfaces where transients are connected to their parent (they raise to the top together, change workspaces together, and others)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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></blockquote><div><br></div><div>Tooltips are not xdg-shell windows. They should either be subsurfaces or we should invent a new type of xdg-transient.<br><br></div><div>I want to support hints to determine whether windows are modal dialogs are not. The issue is that after you eliminate transient windows, there aren't many types left besides "normal window" and "modal dialog", and it may not be worth it to add a new request for that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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>As Jason explained, this is very difficult to do securely. My personal opinion is that it doesn't need to be ultra-secure, because the worst thing that could happen is that focus-stealing prevention doesn't trigger, which would already be the case if the user doesn't call the method in the first place.<br><br></div><div>_NET_WM_USER_TIME is insane and power-hungry and I'm never supporting anything like it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Best Regards<br>
Martin Gräßlin<br></blockquote><div><br></div><div>Thanks for bringing this up! I've been stalling on xdg-shell work for a while now.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] weston/protocol/xdg-shell.xml as of<br>
b502654b9fd9263964ccc4bdcbd8d633233b4f87<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">  Jasper<br></div>
</div></div>