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

[Juan Zhao]

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. 
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.

Thanks,
Juan