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

Fri Aug 10 00:30:32 PDT 2012

On Fri, 10 Aug 2012 13:23:34 +0800
Juan Zhao <juan.j.zhao at linux.intel.com> wrote:

> Thanks for your reply.
> Still don't understand why not implement wl_shell on tablet_shell to
> customize it for a embeded system.

Sorry, I don't think I can explain it any better, but I'll try.

> wl_shell interfaces were defined in compositor side, in
> wayland/src/wayland.xml.
> Most client applications used them. 

Yes, because so far we have been targetting only the desktop.

There once were plans to move wl_shell out of the core protocol file,
but it didn't happen. I still do not consider wl_shell as part of the
core Wayland. It is just a too important extension on the desktop to be
moved out now, and that is also why it fell under the protocol freeze
and stability requirement with 0.95.

> Desktop shell implement one for desktop enviroment. And it works cool.I
> like it.
> 
> For embeded environment, implement a special one according to its usage.
> And allow the client applications works cool here too.
> Why should we force the applications for tablet-shell to be special, and
> not to use that general wl_shell interfaces? And raise a bar for them?
> For example, calculator, memo, or even webkit.
> 
> Do you mean, there is some problems with this direction?

Yes, I tried to explain that with the help of the Gimp.

Have you ever tried any application that is using more than one
top-level-like window? Or even apps with dialogs on tablet_shell?

> BTW, GIMP is a window with several sub-windows. So we send a event to
> tell the client: please set fullscreen to avoid such conditions.

I think you have only seen the new(?) Gimp GUI. The traditional one
looks like this (the WM is fluxbox):

http://people.collabora.com/~pq/gimp-gui.png  (1.6MB)

How would you manage the windows of such an application on a tablet,
given that the application is using the wl_shell interface?

If you implement wl_shell in the tablet-shell environment and it works
fine, then what do you need the tablet_shell protocol for? Desktop-only
apps won't use it anyway. You ended up creating another desktop window
manager, not a new shell. The point of tablet_shell, as it is in the
Weston repository, is to be a new *shell*, not another desktop window
manager.

If apps did use tablet_shell protocol, then your point is moot: the
application is already explicitly modified to use tablet_shell. Also,
the same reasoning applies, if apps need to change their way of using
wl_shell, when they run on tablets. It introduces tablet-specific code
into the application, except it will be messier.

My postulate is, apps using wl_shell cannot work fine on a tablet
environment. The GUI will be somewhat unnatural the least, if not
misbehaving.

I am starting to believe, that you want to write another desktop window
manager. The problem with that is that you are trying to do it in
tablet_shell, which is another shell, not just a window manager. Would
it not make more sense (conceptually) for you to fork desktop-shell
instead? You are still free to replace the private desktop_shell
protocol with whatever, as long as you keep the public wl_shell.

Hmm, or what about this: you use the desktop-shell plugin, and let it
handle wl_shell protocol, but replace only the desktop-shell client?
The configuration of desktop-shell plugin could say which special
client to launch. Then you could write a tablet-shell client replacing
the desktop-shell client, and get a tablet-looking *desktop*. It
would still be the same desktop window management, but with a
different GUI. How'd that sound?

Thanks,
pq

> 
> Thanks,
> Juan
> 
> On Thu, 2012-08-09 at 10:07 +0300, Pekka Paalanen wrote: 
> > 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
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 