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

[lionel at olpc-france.org]

> we are more or less understanding each other :) 

Yes you’re right, great to hear that finally we talked about the same thing
:-)


> 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. 

> 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.


> 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,

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


> I don't want to be stuck in our own html based framework. I explained in
my first email why I think we should jump on one of the existing webapp
frameworks train.

Yes you’re probably right. BTW others threads in this list (talking about
Sugar unique features: Journal, Collaboration, 
) make me thing that Sugar
need a specific framework.


> Anyway I'm satisfied that we know what are the alternatives now. And we
have a pretty decent idea of what they involve. I think when Simon is back
we should meet and decide which direction to take. It also somewhat depends
on who is interested to help out with this and what they would like to work
on.

+1

I’m very happy of our exchange on this.


> In the meantime people can start hacking on the UI stuff :)

+1

The first work is probably to list Sugar specific controls and functions. I
guess that a good start is sugar.graphics in
http://doc.sugarlabs.org/epydocs/.

                Lionel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/fdeb65c6/attachment-0001.html>