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: <a href="http://www.youtube.com/watch?v=h384z7Ph0gU">http://www.youtube.com/watch?v=h384z7Ph0gU</a> 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. <div class="gmail_quote">On Wed, Feb 13, 2013 at 12:05 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Tue, 12 Feb 2013 17:45:12 -0800 Nick Kisialiou <<a href="mailto:kisialiou@gmail.com">kisialiou@gmail.com</a>> 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. </div>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 </blockquote></div>