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

[Daniel Narvaez]

On 13 April 2013 16:08, <lionel at olpc-france.org> wrote:

> > My feeling is that we should target step 2 directly, because 1 -> 2
> will waste too much work. The datastore and collaboration implementation
> is going to be pretty different, depending if we use Chromium or Webkit
> embedding.
>
> Not so waste than that. The step 1 need only to map a set of JavaScript
> functions to a set of Sugar functions. Once the list of Sugar functions is
> write, it’s not very complex to do. Except for the UI part, the Sugar
> JavaScript framework the process is pretty dumb:  call the right Sugar
> function. Step 2 will need more intelligence.
>
I think it would be easier to evaluate if someone wrote down a proposal for
the js API :)

> ****
>
> > Consider also that a better way to communicate then "console-message"
> is not going to come for free.****
>
> Good point. I must admit that I don’t know how to do that. BTW I wonder
> how PhoneGap/Cordoba is working. Because it has really the same thing to
> do: map a JavaScript API to system features (GPS, Phone, Camera, …). Plus
> PhoneGap/Cordoba is browser agnostic: it works on Android, Safari,
> BlackBerry, Windows Phone, webOS, … If we could retrieve and understand
> what sort of communication PhoneGap/Cordoba use, it could inspire us.
>

Well, it's OS specific, but generally quite hacky. Slightly better than
console-message though :)

Maybe the iOS approach could work for us. They load a gap_exec url inside
an iframe, when the WebView notices that, it evaluates some kind of
fetchMessage() method and handle the result.

Or if the iframe thing doesn't work you could poll but ugggh. They are
actually doing that for some version of android, for the opposite direction
though.

In WebkitGtk2 you can actually get the result of execute_script (though
probably only from C code, you would need to wrap that up in sugar-toolkit
or something).

> The only real advantage I see with doing step 1 first is that it would
> give us more time to migrate Browse to the same backend.
>
> Not the only advantage. Another advantages I see:****
>
> **-          **Easier to do for a student,
>
I agree on that. But I _hope_ we will have more people working on this, not
just the GSOC student.


> ****
>
> -          No need to change Sugar, so the framework will be compatible
> with Sugar 0.96/Sugar 0.98,
>

Assuming you are willing to keep using console-message there :) It's
probably the only possible approach on that webkit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/2f4945a3/attachment.html>