Developing a core shell protocol

[Nick Kisialiou]

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

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?

Thanks,
Nick

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130220/62d6de9f/attachment-0001.html>