Developing a core shell protocol

Tue Feb 12 17:45:12 PST 2013

Actually, there is a value in clients that need 2 shells at the same time.
Think about an SDK or a development environment for a phone OS. The
development environment would work in a desktop shell because it is more
convenient for developers to write code in an IDE on a desktop/laptop. At
the same time, it would dispatch the phone app to the phone shell for
execution or debugging. There are other examples as well, e.g. running
regression tests of the phone OS on a desktop/server, debugging phone
hardware or networking bugs, etc. There is probably not much value for the
end users, but for developers and for quality of the apps/OS there is a lot
of benefit.

Nick

On Tue, Feb 12, 2013 at 11:54 AM, Pekka Paalanen <ppaalanen at gmail.com>wrote:

> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130212/70e41445/attachment.html>