Developing a core shell protocol

[David Herrmann]

Hi Jason

On Mon, Feb 11, 2013 at 5:52 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> Perhaps I should be asking a better question.  That question would be,
> How should alternate compositors be handled?  Perhaps the best answer
> isn't to change wl_shell, but to simply break it in a reasonable way
> such as ignoring requests by the client to move the window.  I guess
> my concern is that, since having to constantly break the X spec is
> something we're trying to get away from, is breaking the Wayland spec
> really the right way to do this?  Is completely ignoring move/resize
> requests actually breaking things?

I think one important thing Pekka noted is that there is probably no
use-case for a shell-protocol that serves them all. That is, what
application could you possibly develop that makes sense on all kinds
of compositors? I would say none. Hence, why try to support _all_
kinds of compositors?

I'm not against a common subset between similar shells, but a "one
kind to serve them all" doesn't make sense in my opinion.

I also did some work on a tiling-compositor and what I did is to
simply support both, wl_shell and an experimental wl_tiling_shell. The
compositor then doesn't implement wl_shell in the conventional way but
tries to do its best to display wl_shell clients the way they
intended. (or has some "wl_shell-emulator")

It's just that I don't believe that it makes sense to find a common
subset between tablets and desktops. Because an application would then
have to decide what to support.
If the common-subset is of a too "wide-scope", then it is too
unspecific that it makes any sense. And if it is too "narrow-scope"
then it will be hard to make it work on all kinds of compositors.

A common-subset would make all apps work on all kinds of compositors,
but would the apps make any sense then? That is, what can they provide
with this limited subset so you would actually use it? You wouldn't
have any system integration, no nice handy features, no compatibility
to the other stuff on the system, and so on.
So in this case you could _use_ the app, but it wouldn't be fun. And I
doubt anyone wants to write their app using this limited subset just
to make it work.

And note that this only makes the graphics-output work across the
systems. For instance if Android used Wayland, could you now have the
Android app work on your linux desktop? No, because even with a
unified graphics output, you'd still have to provide a port of the
other Android specific stuff (like connectivity, sound, ...). So why
bother? If you emulate all the other stuff, why not also emulate the
graphics-layer?

So keep that in mind. A common shell subset doesn't mean the apps will
be easier to work across systems.

Cheers
David