[RFC PATCH 06/12] tablet-shell: Applications can run on tablet
juan.j.zhao at linux.intel.com
Sun Aug 12 18:53:56 PDT 2012
On Fri, 2012-08-10 at 10:30 +0300, Pekka Paalanen wrote:
> On Fri, 10 Aug 2012 13:23:34 +0800
> Juan Zhao <juan.j.zhao at linux.intel.com> wrote:
> > 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.
Fine for targetting desktop, I also hope it could run well on embeded
> 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.
So do you mean, one day, wl_shell will be moved out of the core Wayland?
(If so, that's fine for me. I did not not notice such info in the
I thought wl_shell located on core wayland is because of it provides the
base shell interface for all shells, and then each shell will have its
extra interface to provide special, for example desktop-shell will
provide desktop-shell-xxxx APIs and tablet-shell will provide
And this makes sense. Because, the shells should have some common
behavior, for example, set_fullscreen, ping & pong.
For those general usage, there is no need for desktop-shell to define
one set of APIs and tablet-shell to define one set of APIs.
And to make it better, maybe we can move some special usage for desktop
to desktop-shell, for example move. But this is just some slight
modification, not all of them should be moved to desktop-shell.
Any way, these are just my 2 cents about wl_shell. krh must have his own
ideas to locate wl_shell. I will follow the convention once the decision
> > 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.
I definitly know Gimp, I like to use it to make images to get rid of
fees that photoshop charges.
That's something we're considering about. Only because in embeded
environment, we did not see much usage like GIMP. So, it's still under
consideration. I have to say it's really really a desktop application,
and because I think tablet-shell may also need some simpler
image-processing tools, so it's still under consideration.
And it could be resolved by noticing that "You'd better make your self
fullscreen, because we're in tablet-shell". And the client did some
modification. Although still not sure such cases are very important in
> Have you ever tried any application that is using more than one
> top-level-like window? Or even apps with dialogs on tablet_shell?
We've tried elementry_test which will launched a new surface. It's an
applications who provides several surfaces.
And not sure, whether there would be so many cases who uses more than
one top-level-like window.
Again, this is just the first step to initiate, not a done status. To
make it better and better, lots of refine work to take. We just hope to
hear key maintainers' opinions here.
> > 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?
Other than this application, we still have calculator, memo,
image-viewer, messages, clock, and even webkit many applications who is
much more important for embeded systems.
More information about the wayland-devel