Developing a core shell protocol

[Jason Ekstrand]

Wayland Devs,
This is a brainstorming e-mail concerning trying to develop some sort
of core shell protocol.  I will shortly begin work on developing a
touch-based compositor for phones and tablets and there have been
multiple discussions on IRC concerning trying to implement tiling
WM's.  There are probably several more use-cases that do not fall into
these lists.

The problem with the current protocol is that wl_shell is, in the
words of krh, "inherently desktopy".  I believe the intention is that
different kinds of compositors will simply implement different
protocols for putting a surface on the screen.  However, many of these
different types of compositors are still shells in the sense that they
provide a mechanism for users to run other applications.  Right now,
if an application is written without knowledge of your specific shell
type, it won't work.  This is going to cause massive problems for
alternate shells because old or lazy software won't run on them unless
they try and implement the desktop protocol which is going to be a
hack.

In order to solve this problem, I am suggesting that we effectively
split wl_shell into two components: a core shell interface, and a
desktopy shell interface that extends the core shell interface.  Then
we could write a set of other shell interfaces that each extend the
core shell interface and provide additional functionality not provided
by the core.  This way, if an application is written without knowledge
of a particular shell, it can use the core as a fallback to at least
display and work to a certain extent.  Please note that I am referring
to compositors that act as shells allowing the user to run external
programs.  Special purpose compositors such as login manager are
probably still going to have to be a special case.

If this is to happen, there are a number of questions that need to get
answered (I'm sure this list is incomplete):

1) What things are common to all shells?  In order to answer this, I
think we need to look at a lot of use-cases such as standard desktop
WM's; touch-based WM's such as Android, iOS, or ModernUI; and tiling
window managers.  If anyone knows of other eclectic shell schemes,
those should go on the table too.

2) Is it even feasible to try and make a lowest-common-denominator
shell interface?

3) What are the UI implications of an application only handling the
core shell? How do we make that application work in a sensible way
without the application providing the shell all the information it
would like?

4) What about decorations? Right now, wayland always assumes
client-side decorations and the client simply decorates top-level
windows. However, this leads to a number of problems.  Tiling WM's for
instance don't decorate the same way others do, and a touch-based WM
might not decorate at all.

5) How do we handle the migration path? Do we simply add another
wl_core_shell interface, or do we deprecate the desktoppy parts of
wl_shell and add wl_desktop_shell to implement those?  Really, this is
probably the last question to answer.

Giving it a brief look, I think the following can probably stay in the "core":
 * ping and pong
 * set_toplevel
 * set_transient (although positioning might not work exactly the
same. we need to think about that)
 * set_fullscreen
 * set_name
 * configure

and the following probably are specific to the desktop shell:
 * move
 * resize
 * set_maximized

Note: When I say wl_shell above, I also include wl_shell_surface, as
the two interfaces are inherently tied together.  Each shell interface
is going to be accompanied by a corresponding surface interface.

I'm interested to hear everyone's thoughts.
Happy Brainstorming,
--Jason Ekstrand