Feedback on xdg-shell from Plasma crew

[Pekka Paalanen]

On Mon, 15 Dec 2014 13:16:24 -0800
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> On Mon, Dec 15, 2014 at 5:30 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> >

...

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

Heh, yeah, I am personally not in either GNOME or KDE camp, I use
fluxbox everywhere, so I'm perhaps less biased than several other
people, but I also don't have a clue about how a modern desktop works to
begin with. :-)

That's why I have tried to stay away from the xdg_shell design, apart
from checking the low-level mechanical details.

However, I am influenced by the contributions and discussion I see on
wayland-devel@, and I'd expect others are too. It's very refreshing to
see someone from the KDE side. Appreciated!

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

Yes, it's a tough question.

Some ages ago, it was thought that tablet devices would be using a
shell protocol that is not a desktop shell (xdg_shell). Each fundamental
type of graphical environment would use it's own, tailored shell
protocol. While making apps blend in better, the obvious major drawback
is that apps (toolkit) must then support many or all of these shell
protocols. That's pretty harsh.

Maybe we could do it less painfully? It seems xdg_shell is becoming the
common factor of all "desktop-like" environments. Environment specifics
could be additional protocol extensions, that are not mandatory to use,
but would help apps to blend in. Whether those are per form factor, or
per DE, I can't say, maybe both kinds.

The main wish I have is that we could stabilize xdg_shell version 1
soon, not fully featured, not even close, but something apps can start
to rely on, just to run at all. I hope better DE integration can be
built incrementally, extending xdg_shell when it makes sense, and adding
optional(?) extensions when they make sense.

Maybe the always-fullscreen etc. use cases would be close enough to the
tiling window manager concept, so that they could use the same protocol?
If you consider tiling WM a concept to support, I know there are people
who would want it.

Jason had very good comments on the decorations issue who does what
when, in my opinion. If we can agree on some solution to that, the
xdg_shell version 1 would be pretty close, don't you think?


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

Could that perhaps be allowed by allowing state changes with bad
serials only before the window is mapped?


Thanks,
pq