shells (Re: [PATCH weston 4/5] Make use of new wl_cursors)

[Pekka Paalanen]

On Wed, 25 Jul 2012 14:37:47 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Kristian Høgsberg wrote:
> 
> > We added wl_shell_surface, because we had a lot
> > of requests on wl_shell that went like: wl_shell.set_fullscreen(shell,
> > surface), ie, took the shell and a surface, and in effect were surface
> > requests.  So the wl_shell_surface is almost just protocol syntatic
> > sugar, and I'm not always sure it actually makes things clearer.
> 
> That is very informative! I have to say I was pretty mystified by the 
> wl_shell_surface object.
> 
> Though this implies that there can be more than one shell. Because if 
> there is only one shell there is no need for that argument, and the api 
> can just be "wl_shell.set_fullscreen(surface)".

The 'shell' in wl_shell.set_fullscreen(shell, surface) is just the "this"
pointer to the wl_shell object. It is an object method invocation in
pseudo-C.

> What is the meaning of more than one shell? Or is there another reason 
> for the shell argument?

A shell does window management. For your usual Linux desktop, we
have wl_shell, or in the future probably wl_desktop_shell. This
shell supports concepts like non-fullscreen, stackable windows,
certain ways of assigning input foci to surfaces, it understands
window types like top-level, pop-up, tooltips, transient stuff etc.
Our desktop shell assumes you have keyboard and a pointer device.
It has some hotkeys, and responds to pointer events in a certain
way, the way people are used to when using desktop environments.

The traditional X window managers would be something like
sub-classes of the desktop shell. They may not need different
protocol and hence applications would not need to particularly
support different "window managers", but the behaviour would be
different, e.g. a tiling window manager. But it would still be
a desktop shell.

We also have a tablet shell, which is very minimal for now. It
is aimed for portable touch screen devices, that usually have no
keyboard, but have a touchscreen (or a pointer). Window management
is very different to a desktop shell. It has dedicated home screen,
lock screen, etc., which concepts do not exist on a desktop shell.

The following differences may not apply to tablet shell, but
they are possible. Think about e.g. smart phone GUIs, TV
set-top-boxes, car entertainment systems.
- all applications are either visible fullscreen or hidden
- set_fullscreen on/off request makes no sense
- window positioning may be fixed, unmovable
- user interaction with the GUI is based on a very different
design, e.g. touchscreen only (more of an issue for the shell
client component than the shell plugin).
- window typing may be different, e.g. only "top-level" windows,
and no pop-ups, or
- window typing may be restricted, in that you may not have an
arbitrary amount of windows. Maybe in a TV one could be restricted
to the particular windows: tv-image, info-overlay, controls-overlay,
PiP-image.

For instance, when Android gets proper Wayland support, I suspect
it will need an "android shell", because a "normal" desktop shell
would be a poor match for the Android GUI concepts and window
management.

I hope these examples allow you to think about Wayland in other
devices than traditional computers. When you realise that, many
design choices you now think are strange will clarify.
Wayland (core) is not only for desktop environments.

And yes, applications will have to know the shell they are running
with.


Thanks,
pq