[Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)

[William Orr]

I'm pretty new to the mailing list and the project, but I'm pretty sure 
that starting a new Chrome instance for every launched activity is far 
too taxing for the XOs.

I think that Lionel's idea of using a Python activity that uses the 
WebKit WebView is a much, much better solution.

> lionel at olpc-france.org <mailto:lionel at olpc-france.org>
> April 12, 2013 4:36 PM
>
> Hi Daniel,
>
> Impressive idea with a cool architecture. BTW, to be honest I think 
> it's... too complex.
>
> Why not just create a standard Python activity template that call the 
> WebKit WebView? Like we do today.
>
> But maybe I miss something or maybe we don't speak of the same thing?
>
> When I wrote the GSoC proposal, I think to a two steps process.
>
> What I call the "first step" is just to create an activity template 
> with a full screen WebView control and a Sugar to JavaScript.
>
> So it's like my work on Enyo today but:
>
> -With a better way than "console-message" to communicate between 
> JavaScript & Sugar,
>
> -With a JavaScript/CSS framework to reproduce in HTML5 the Sugar 
> Look&Feel and sugar.graphics stuff,
>
> -With a JavaScript framework that allow calling all Sugar features 
> (telepathy, data store, l10n, drag&drop, ...).
>
> We could probably do all these things without lot of change on current 
> Sugar implementation and current Sugar activity way of working. In my 
> mind, this could work even on Sugar 0.96-0.98 without any change!
>
> Except if I'm wrong, what you're currently describe is the "second 
> step": upgrading Sugar to support directly HTML5 activities.
>
> In this second step we could imagine that Sugar will be very different 
> than today (may be an Android layer or a Chromium layer) and that no 
> current Python activities will work on it. BTW HTML5 activities built 
> with the "first step framework" should be very easy to adapt: just 
> need to change the JavaScript framework implementation to use natives 
> features instead of Sugar Python features (for example: call HTML5 
> storage instead of Datastore storage) and remove the XO 
> Manifest/Package. I do like your architecture proposal for this second 
> step but it's difficult to me to think to this second step without 
> we've got a more precise view of the first step.
>
>                 Lionel.
>
> *De :*Daniel Narvaez [mailto:dwnarvaez at gmail.com]
> *Envoyé :* jeudi 11 avril 2013 21:52
> *À :* sugar-devel at lists.sugarlabs.org
> *Cc :* Lionel Laské
> *Objet :* Chromium integration inside the sugar shell (was Re: Kicking 
> off HTML5 activities work)
>
> Hello,
>
> I spent some time today thinking and experimenting with Chromium 
> integration and I have a more detailed plan to propose now.
>
> There is an important premise to be made. In both Chromium and Firefox 
> OS, application's installation is very much in the hands of the web 
> browser. It happens as the result of a user clicking on a button, 
> inside a web store. Chromium is a bit more flexible but the other 
> possibilities are basically just developer tools.
> I think this limits our possibilities a lot. We need to use the 
> browser applications management, rather then installing applications 
> ourselves and then launching them with some command line option. Of 
> course Chromium is open source and we could develop the stuff which is 
> missing. But, in my opinion it's just too much work and it's going to 
> be a pain to maintain in the future, core developers are not going to 
> care about it, given it's not important for their products.
>
> That said, I think I mostly figured out a plan to integrate with 
> Chromium web apps management, without having to write a lot of code.
>
> * Chromium is started up with the sugar session, using the 
> --no-startup-window, to make it invisible. The sugar extension has a 
> "background" permission, which will keep it running even with no windows.
> * The extension runs a python script, using 
> chrome.runtime.connectNative. Communication uses json-rpc wrapped in 
> the message protocol supported by the extension. The python script 
> fetches the list of installed activities (as exposed by 
> chrome.management.getAll) and listen to changes.
> * The python script exposes a dbus service, allowing the sugar shell 
> to get the list of installed applications and to display icons for 
> them in the home. We use GIOChannel to read stdin, so that we don't 
> block and integrate with the glib mainloop.
> * When the user click on an icon, a LaunchApplication is called on the 
> dbus service, which proxies it to the extension, which launches the 
> application. We will probably need a trivial patch to chromium to 
> start it without UI. There is already a define for chromeos, but it's 
> a compile time thing (in extension_prefs.cc, GetLaunchContainer).
> * The shell notices that a new window has been opened and associates 
> it with the application information. This allows to activate and close 
> the activity as necessary.
> * Uninstalling an activity works in the same way as launching. Shell 
> -> python script -> extension.
> * Implementation of collaboration and datastore libraries could also 
> be based on the python script messaging.
>
> I implemented (badly) a good part of this and I didn't find 
> fundamental problems with it. Except for one, which is not specific to 
> this plan. Sugar supports multiple instances of the same activity, web 
> application frameworks doesn't. How are we going to deal with that? I 
> haven't thought much about it yet, but it seems something we want to 
> be very clear about.
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> Daniel Narvaez <mailto:dwnarvaez at gmail.com>
> April 11, 2013 3:52 PM
> Hello,
>
> I spent some time today thinking and experimenting with Chromium 
> integration and I have a more detailed plan to propose now.
>
> There is an important premise to be made. In both Chromium and Firefox 
> OS, application's installation is very much in the hands of the web 
> browser. It happens as the result of a user clicking on a button, 
> inside a web store. Chromium is a bit more flexible but the other 
> possibilities are basically just developer tools.
> I think this limits our possibilities a lot. We need to use the 
> browser applications management, rather then installing applications 
> ourselves and then launching them with some command line option. Of 
> course Chromium is open source and we could develop the stuff which is 
> missing. But, in my opinion it's just too much work and it's going to 
> be a pain to maintain in the future, core developers are not going to 
> care about it, given it's not important for their products.
>
> That said, I think I mostly figured out a plan to integrate with 
> Chromium web apps management, without having to write a lot of code.
>
> * Chromium is started up with the sugar session, using the 
> --no-startup-window, to make it invisible. The sugar extension has a 
> "background" permission, which will keep it running even with no windows.
> * The extension runs a python script, using 
> chrome.runtime.connectNative. Communication uses json-rpc wrapped in 
> the message protocol supported by the extension. The python script 
> fetches the list of installed activities (as exposed by 
> chrome.management.getAll) and listen to changes.
> * The python script exposes a dbus service, allowing the sugar shell 
> to get the list of installed applications and to display icons for 
> them in the home. We use GIOChannel to read stdin, so that we don't 
> block and integrate with the glib mainloop.
> * When the user click on an icon, a LaunchApplication is called on the 
> dbus service, which proxies it to the extension, which launches the 
> application. We will probably need a trivial patch to chromium to 
> start it without UI. There is already a define for chromeos, but it's 
> a compile time thing (in extension_prefs.cc, GetLaunchContainer).
> * The shell notices that a new window has been opened and associates 
> it with the application information. This allows to activate and close 
> the activity as necessary.
> * Uninstalling an activity works in the same way as launching. Shell 
> -> python script -> extension.
> * Implementation of collaboration and datastore libraries could also 
> be based on the python script messaging.
>
> I implemented (badly) a good part of this and I didn't find 
> fundamental problems with it. Except for one, which is not specific to 
> this plan. Sugar supports multiple instances of the same activity, web 
> application frameworks doesn't. How are we going to deal with that? I 
> haven't thought much about it yet, but it seems something we want to 
> be very clear about.
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/493a5cd6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/493a5cd6/attachment-0001.jpg>