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

[Pekka Paalanen]

On Wed, 08 Aug 2012 13:40:33 +0800
Juan Zhao <juan.j.zhao at linux.intel.com> wrote:

> 
> On Tue, 2012-08-07 at 09:36 +0300, Pekka Paalanen wrote:
> > 
> > Looking at the tablet-shell.xml protocol, I wonder if it is missing an
> > interface. The interface tablet_shell seems to be private for the
> > ux-daemon (tablet-shell client), but there is no interface for normal
> > clients. 
> 
> I think tablet-shell is used for embeded systems, like ivi/handset/tv.
> Not only ux-daemon. 

ux-daemon, i.e. the tablet-shell client, is an essential part of the
tablet-shell environment. In summary, the tablet-shell environment
consists of:
- the tablet-shell weston plugin
- the tablet-shell client (a special client spawned by the plugin)
- the private tablet-shell protocol extension for the special client
  only
- the public tablet-shell protocol extension for normal clients

When we talk about these, we should try to be explicit on which part we
mean.

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.


Thanks,
pq