Developing a core shell protocol

[Kristian Høgsberg]

On Sat, Feb 09, 2013 at 12:20:57PM -0600, Jason Ekstrand wrote:
> 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.

As I mentioned briefly in IRC, I don't think there really is a core
subset.  Almost everything in wl_shell is desktop specific.

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

Decorations or not (in the sense that windows are always fullscreen
and never decorated) is a function of the shell in use.  For wl_shell
(desktop) windows are decorated depending on their current state.
Toplevel -> full decorations, fullscreen -> no decorations, maximized
-> titlebar only etc.  For a tablet/phone type shell (think
iOS/Android), applications are always only fullscreen.  Any kinds of
transient windows or popups is part of the fullscreen window contents.
With the exception that something like Pekkas sub-surface extension
still can be used with such a shell to place sub-surfaces over the
fullscreen main window.

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

I've been saying we should deprecate wl_shell and create a new
wl_desktop_shell interface.  We have some false starts and half-baked
ideas in wl_shell, but I now think we're better of just living with
that and add to wl_shell.

One of the things I'd like to do was to split wl_shell_surface into
wl_shell_toplevel, wl_shell_popup, maybe wl_shell_transient.  This
would avoid some "illegal" transitions, like making a popup fullscreen
or setting a name or class for a popup, since those would be
wl_shell_toplevel requests.  Also, making a toplevel fullscreen or
maximized would be a state change, not setting a new type of surface.

> Giving it a brief look, I think the following can probably stay in the "core":
>  * ping and pong

This could be generic I guess.

>  * set_toplevel
>  * set_transient (although positioning might not work exactly the
> same. we need to think about that)
>  * set_fullscreen

These are all desktop specific.  For a tablet style UI, you really
just need to say "this is my application surface".

>  * set_name

Not sure...

>  * configure

The configure event is only useful when you have to negotiate a size.
For a fullscreen-only UI there's only one size.

Kristian

> 
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel