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

[Gonzalo Odiard]

I like the general idea.
Question:
This means a Chromium process should be working all time?

Gonzalo


On Thu, Apr 11, 2013 at 4:52 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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/20130412/d4130cfc/attachment.html>