Feedback on xdg-shell from Plasma crew

[Jason Ekstrand]

Hi Martin!
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*.

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 ;-)
>

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.


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

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.


> In addition there are quite some interaction limitations:
> * configurable mouse actions: a right click might not trigger a context
> menu,
> mouse wheel support
>

It doesn't have to.  The client can use whatever button or key it wants to
use to trigger the context menu.


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

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.


> 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 ;-)
>

Not much you can do about that in some ways.  Then again, maybe Opera is
annoyed that you keep moving their buttons. ;-)


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

Ah, CSD, the age-old argument...  I really hope we can avoid an all-out war
on this.  A few comments in general.

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.

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.

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.


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

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.

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?


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

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.


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

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.

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.

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.
--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141215/9b534022/attachment-0001.html>