Developing a core shell protocol

[Pekka Paalanen]

On Wed, 20 Feb 2013 00:20:04 -0800
Nick Kisialiou <kisialiou at gmail.com> wrote:

> Hi Pekka,
> 
> It may indeed be a cleaner solution to have 2 compositors, a phone
> compositor working as a client of the desktop/laptop compositor. In fact,
> with proper nesting of multiple compositors you may effectively offer
> multiple shells. It is definitely a good solution for an SDK.
> 
> That said, I am still not 100% sure that the nested architecture covers all
> usage scenarios. For example, take a look at Shuttleworth's newly released
> tablet demo at 5:07 where the phone screen gets mapped to a tablet screen
> on the fly:
> http://www.youtube.com/watch?v=h384z7Ph0gU
> 

To me it appears the video is suggesting shell switching on the fly. If
you want that to work seamlessly for any apps, you have to abstract
everything into a general purpose shell interface. Or another way,
which requires explicit app/toolkit support, is to remove the global
object of the old shell, and add a global for the new kind of shell,
and assume that the apps do the right thing and switch.

I cannot imagine that a nested compositor architecture could work for
that, there I agree.

> By looking at this video I can come up with usage models where a tablet
> works as a screen *extension* for a laptop, or a phone works as a *window*
> on a screen of the connected tablet. I am not sure if this is where the
> graphical interface is headed but there are some good ideas in that demo.
> Is nested architecture flexible enough and fast enough to cover such usage
> models?

Depends on how want things to behave. Are the new devices just
extension outputs with a bit of input device, or should it actually
cause application behaviour to change. If you don't need application
behaviour to change, I think you can do all that within a desktop shell.

Or are you perhaps suggesting that an application should be properly
using *all* the shell interfaces a server offers (and the app knows
about), and then the server would choose which shell state it would
actually use? An interesting thought, but I suspect there will be a lot
of conflicts, and the application would still not directly know for
which platform it should be rendering.

Room for research, I guess.


Thanks,
pq

> Disclaimer: the video above should not be misconstrued as an endorsement of
> Ubuntu. Neither do I express my opinion for/against this tablet interface.
> 
> 
> On Wed, Feb 13, 2013 at 12:05 AM, Pekka Paalanen <ppaalanen at gmail.com>wrote:
> 
> > On Tue, 12 Feb 2013 17:45:12 -0800
> > Nick Kisialiou <kisialiou at gmail.com> wrote:
> >
> > > 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.
> >
> > Hi Nick,
> >
> > I don't think that is a good idea. I bet the SDK would not want to be
> > at the mercy of whatever compositor the user is running for his desktop
> > session. The SDK emulator probably wants to provide the phone
> > compositor, so it can guarantee its features and behaviour. I also
> > believe the emulated compositor coming with the SDK would include
> > debugging features which would not be present in a desktop session
> > compositor, tailored for the specific target OS.
> >
> > Also, note that we were talking about a single client using two shells
> > at the same time. You will probably run your IDE and the phone app in
> > separate processes, so they cannot be the same client, no?
> >
> > As for regression tests, hardware and networking debugging etc. you
> > mention, I really do not understand how they are relevant here. Don't
> > you run those on the phone or a VM?
> >
> > The purpose of having a phone shell interface available on desktop
> > compositor would be just for being able to run phone apps. I don't see
> > it as useful for developing phone apps for a phone, only for phone apps
> > for the desktop. The phone shell interface on a desktop compositor
> > would not pop up a phone emulator but try to integrate the phone app
> > with the desktop environment the best it can, i.e. turn the phone app
> > into a desktop app, in my opinion.
> >
> >
> > Thanks,
> > pq
> >