Feedback on xdg-shell from Plasma crew

[Jasper St. Pierre]

On Mon, Dec 15, 2014 at 5:30 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
>
> 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.
>

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.

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.

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].

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.

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. :)

[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.
http://www.google.com/design/spec/style/color.html#color-ui-color-application


> 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.
>

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.

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.

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.

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"?
>

At the time of writing, the desktop-entry spec was recently updated with a
new recommended naming convention for applications. [1]

The "app ID" is meant to be "org.example.FooViewer", without any ".desktop".

>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.

[1]
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#basic-format
[2]
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus


> * 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.
>

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.


> * 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?)


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?


> * 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.
>

Why can't my game start fullscreen, or my web browser start maximized?


> * 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.
>

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.


> * 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
>

I'd be fine with extending this. A patch would be welcome.


> * 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?
>

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)


> * 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.
>

Tooltips are not xdg-shell windows. They should either be subsurfaces or we
should invent a new type of xdg-transient.

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.


> * 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
>

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.

_NET_WM_USER_TIME is insane and power-hungry and I'm never supporting
anything like it.


> Best Regards
> Martin Gräßlin
>

Thanks for bringing this up! I've been stalling on xdg-shell work for a
while now.


> [1] weston/protocol/xdg-shell.xml as of
> b502654b9fd9263964ccc4bdcbd8d633233b4f87
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141215/fc57e774/attachment.html>