[RFC PATCH 06/12] tablet-shell: Applications can run on tablet

[Pekka Paalanen]

On Thu, 09 Aug 2012 03:04:53 +0800
Juan Zhao <juan.j.zhao at linux.intel.com> wrote:

> On Wed, 2012-08-08 at 12:18 +0300, Pekka Paalanen wrote:
> > 
> > The applications, i.e. the normal clients, are yet another thing.
> > 
> > What I meant was that the two different protocol extensions were not
> > separated properly in tablet shell. In the desktop shell, the public
> > protocol extension is wl_shell, and the private protocol extension is
> > desktop_shell.
> > 
> > > > When a client initialises, the set of advertised global interfaces
> > > > will
> > > > contain either wl_shell or tablet_generic, or at least the client
> > > > should
> > > > bind to only one of the two. If it binds to tablet_generic, if
> > knows
> > > > it
> > > > has to be full-screen always, it doesn't need an event to tell it
> > > > that.
> > > > How does it know what size to make its surface, I don't know.
> > Looking
> > > > at outputs or add a configure event?
> > > 
> > > Do you mean the client itself should know it was working for
> > > tablet-shell and need some modification?
> > 
> > Yes, exactly. As the very first thing, it needs to know to expect the
> > global interface "tablet_shell" instead of "wl_shell".
> > 
> > If the server indeed advertises only tablet_shell, and not wl_shell,
> > the application cannot use any of the window management or other
> > features offered by wl_shell (or by wl_shell_surface).
> > 
> > Right now, if the application does not know how to use "wl_shell", it
> > will never get its window shown in a desktop-shell environment. That
> > is
> > intentional.
> > 
> > > I think the client should not have to know that, or take some
> > action.
> > > If the client response to the the event tablet-shell send, then it
> > could
> > > do some configuration to it. 
> > > If the client doesn't response, then it could work usually, then
> > > tablet-shell will add a black surface under it, to make it looks
> > like
> > > fullscreen.
> > > In this way, tablet-shell could easy to support the toolkits who
> > don't
> > > add support to tablet-shell, for example efl applications.
> > > Then the application development will feel easy to support both
> > > desktop-shell and tablet-shell.
> > 
> > No, the application cannot work "as usual", if there is no wl_shell
> > advertised. Applications (read: toolkits) have to explicitly support
> > the
> > different basic shells. Your use case is just one special case, and
> > such "fallbacks" are not generally acceptable. Yes, the toytoolkit
> > does
> > not support tablet_shell, it simply tries to not crash if there is no
> > wl_shell.
> > 
> > Tablet_shell is not simply a desktop adaptation for a tablet. It is
> > supposed to be a completely different environment. A smartphone might
> > be a better example, since tablets just might work with a desktop-like
> > environment.
> > 
> > Now, this does *not* mean that toolkits need to explicitly encode
> > support for all the possible shells out there. I expect Gnome,
> > KDE, Xfce, Enlightenment, etc. to provide their own desktop
> > environments with their own "shells", but the difference to
> > tablet_shell is, that they are all desktop shells. Therefore they all
> > will support the basic desktop shell protocol extensions (that is
> > wl_shell), and they can add more for their special needs. None of the
> > special needs will conflict with the basic desktop shell concepts.
> > Tablet_shell on the other hand does conflict, and cannot support all
> > the basic desktop shell operations.
> > 
> > That is the idea, at least.
> > 
> > As a summary to everyone considering the above tl;dr and wanting to
> > write a WM:
> > 
> > Tablet_shell is *not* the example to base your own "desktop window
> > managers" on. Instead, you want to fork the desktop-shell plugin,
> > the special client, and the private desktop_shell protocol, and keep
> > the public wl_shell protocol.
> > 
> > Also note, that the wl_shell protocol extension can still be developed
> > further, inspite of the freeze, in a backwards compatible manner.
> > wl_shell is not complete yet in any sense. 
> 
> The window manager could run on desktop environment and can also run on
> embeded environment. For example, when in embeded environment, it would
> set all clients fullscreen by setting WM state.  And the client don't
> need to know where it is.

Like I said, if you want to do that, then you are not writing a
tablet_shell. You will be writing a wl_shell implementation, that just
acts slightly differently depending on which kind of device it is being
run on.

Tablet_shell is for devices where wl_shell does not make sense.

Actually the difference in when to use wl_shell and when to use
tablet_shell is not so much about the device, but more about the
graphical environment. You want a desktop-like environment on a tablet?
Sure, implement wl_shell. Want something special and completely
different, like for a TV? Invent your own basic shell like tablet_shell
does.

TV is actually a nice example, since in the most basic setup, the only
input device you have is the remote control, which could be handled as
a keyboard. No pointers, no touch devices. The GUI would not have
arbitrary windows like a desktop does. That is a case where you would
really want to do a wholly new shell.

Now, the difference between shells can be a lot more subtle. Take Gimp,
for instance. Traditionally it opens several windows, for canvas,
toolboxes, etc. In a tablet_shell environment that simply cannot work,
since every top-level window is fullscreen. Gimp must explicitly adapt
to tablet_shell and remake its GUI. If instead you used wl_shell, and
modifed it to always request every window as fullscreen, and tried to
mimick the tablet_shell behaviour, Gimp GUI would be unusable, because
Gimp would not have any clear indication, that the desktop environment
is acting weird here. Gimp would attempt to manage its windows like on
a normal desktop shell, perhaps refusing to fullscreen toolboxes etc.
and that would be a disaster.

> And any of the client don't need to know which compositor it works
> against. For example, efl and gtk clients could run on any window
> manager. efl and gtk for Xorg only differenciate Wayland/Xorg, but not
> pay attention to which window manager the platform would be.
> 
> To make the application writer easier, I suggest to make clients running
> on tablet-shell easier.
> 
> I'm still open on this point, welcome to add any further comments.

We need to distinguish three different things here (towards Wayland
clients):

- compositors
	All Wayland compositors are indistinguishable by definition,
	since they are Wayland compositors. They only differ in the
	global interfaces they advertise, and for general purpose
	compositors, we should aim to support the same minimum set of
	globals everywhere. For instance, all desktop compositors
	should implement wl_shell.

- shells
	Explained earlier in this email. Different shells have
	fundamental differences.

- "window managers"
	The X Window Managers correspond to different wl_shell
	implementations, not different shells, since they pratically
	all deal with a desktop environment.

I understand there could be special purpose X Window Managers, that
would better correspond to their own shells. These window managers
might not implement e.g. EWMH by the spec.

When you think about all this, and think about tablet GUIs for
instance, aren't good tablet GUIs somewhat different to desktop GUIs? I
would assume they are, since on tablets, you usually poke the screen
with fingers, don't have a keyboard, etc. That means applications and
toolkits must already explicitly adapt to tablet environment. In
Wayland protocol, we simply make the distinction explicit: you get
either wl_shell or tablet_shell.

Then how to run an application written for the desktop, on a tablet?
I'm not sure what the answer here should be. Should the server
advertise wl_shell in addition to tablet_shell? If there are several
shells advertised, how would the client know which to prefer, if it
supports several?

In that specific case of a desktop app on a tablet, the wl_shell
implementation could be a "sub-shell" of the tablet shell. All windows
from the wl_shell application would be mapped to a single tablet shell
"view", within which they would work a bit like when you have the
application alone on a virtual desktop, without loosing the tablet
shell gestures and other UI. Or something like that, trying to think
about how the Gimp multi-window GUI could work on a tablet.

To me it seems there are no easy or simple solutions, if you want to
have the roughly the best possible user experience in every case.

The good news is that Wayland does offer a standard way to advertise and
implement everything properly. The "bad" thing is that applications that
try to fight against the server will invariably lose, which makes
writing quick hacks near impossible (unlike X).


Just my 2c,
pq