Developing a core shell protocol

[Pekka Paalanen]

On Tue, 12 Feb 2013 09:13:16 -0600
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Tue, Feb 12, 2013 at 2:52 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Tue, 12 Feb 2013 08:51:26 +0100
> > Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> >
> >> On 11.02.2013 11:06, Pekka Paalanen wrote:
> >> > I want to make sure again, that when we talk about shells in Wayland,
> >> > we usually talk about public shell interfaces in the protocol. Therefore
> >> > all of Linux desktop, regardless of DE or its components (KDE, Gnome,
> >> > gnome-shell, kwin, ...) are under the one and same shell for desktops.
> >> > This is about the generic shell interfaces towards all applications, of
> >> > course, that can somehow make sense on any DE.
> >>
> >> Not exactly. Android, Ubuntu and KDE publicly aim to work on all form
> >> factors. How will a desktop only wl_shell, as you outlined, serve those
> >> projects concepts?
> >
> > I can imagine two choices there:
> >
> > A. Have separate, form-factor based shell interfaces, that will make
> > applications adapt to the fullest for the form factor in use. Pro:
> > top usability and integration. Con: you actually have to implement each
> > shell interface in every compositor and toolkit (toolkit, not
> > application, as toolkits should be able to abstract the form factor
> > towards app code).
> >
> > B. Just use wl_shell, the desktop shell interface, but try to adapt its
> > compositor side implementation to each form factor. Toolkits and
> > applications would not be directly aware of the form factor at all.
> > Pro: just one version of toolkit code needed, so all applications
> > will just work somehow. Con: usability might not be that
> > good, integration will suffer.
> >
> > There's also the third option: A+B. If it makes some sense to run
> > desktop applications on the system of your choice, your compositor can
> > implement wl_shell in addition to the specific shell interface.
> > Applications written to support the specific form factor will use the
> > specific shell interface, and other will use wl_shell. All apps will
> > work, some better than others.
> 
> I think this is what I'm ultimately going to end up doing.  I'm
> probably going to implement wl_shell for fallback for badly written
> apps along with some sort of touch shell and probably.  One big
> question here is how, when we export both wl_shell and wl_phone_shell,
> do we tell applications which one to prefer and ensure that they don't
> try and bind both?

I would assume that applications would prioritize shells, if there
are more than one available as globals in the protocol. Always take
the most specialized you know of. Could that work?

Could we need desktop environments that offer specialized shells as
fallbacks for apps that are written just for one special
environment? I.e. have several shells available, yet the desktop
one would be preferred, in which case the most specialized
-heuristic would fail?

The selection of available shell interfaces could be the hint to
the application or toolkit on which kind of device it runs on.

As for using more than one shell in one client, there are different
levels to handle it:
- issue a protocol error as early as just binding to a second shell
- issue a protocol error when a client tries to mix up shells on
  one wl_surface or such

> > I agree with David Herrmann. Can you really write a good application
> > without caring about the form factor at all? Or is it possible to
> > abstract the form factor issues in the toolkit well enough, so that
> > application code would be completely form-factor independent?
> 
> No, I don't think you can.  Probably the most brilliant thing Apple
> did when they created iOS and the iPhone was to realize and embrace
> the fact that a phone and a computer are different devices.  I don't
> think we should follow suite with the rest of the world in making the
> bad assumption that you can.  Microsoft's new OS makes desktop users
> who want to use it with a mouse second-class citizens.  (And no,
> Microsoft, making the buttons bigger does not make an app
> touch-ready.)  I have a friend who has an Asus Transformer tablet and
> it makes a great tablet but a not-that-great laptop because everything
> is too touch-centric.
> 
> I think it's better to recognize that phones and desktops are
> different and encourage developers to treat them differently in their
> applications.  That being said, it would be nice to see toolkits also
> recognize this and start building in things to make cros-device
> development more practical.

Indeed, and once we have environment specific code in both the
compositor and clients, why not have an environment specific
protocol in between, which will match the special features well
instead of twisting a generic protocol beyond recognition on its
semantics.

Still, I believe there is much room in making wl_shell more
flexible. Just support for tiling window managers would probably go
a long way, if designed properly.


Thanks,
pq