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

[Juan Zhao]

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

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

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?

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.


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