[Sugar-devel] A prototype of SugarWeb / SugarAndroid - Technical questions

Lionel Laské lionel at olpc-france.org
Fri Nov 15 15:16:45 EST 2013


2013/11/15 Daniel Narvaez <dwnarvaez at gmail.com>

> You could put them outside the activities directory and change the
> loader.js to look there.
>

Nice. I didn't know this require feature.


> Though ideally we would add the activities as git submodules and avoid
> making any change to them... I can't think of a good way to dinamically
> adjust the loader on both Sugar Linux and Sugar Web though. You could check
> the protocol or the user agent I guess, but it feels like a pretty bad hack.
>
>
Okay. I've put all activities in the activities directory just for the
prototype but of course, in the real version product, the "activities"
should just be empty and be use to deploy .XO content.


> I wonder if we should first just fork sugar-web, implement the ideal API
> for Web/Android there and later figure out how reconcile with Linux.
> Reconciling is going to be a bit tricky I think, even more without a clear
> idea of what API we will need for Web/Android. (Thinking of the datastore
> mostly).
>

Hummm. I would be better to avoid forking now. At worse, I think, a testing
condition (if Linux else Web/Android) could be better.



> Yeah or use them conditionally.
>
> Perhaps we need to choose one or two target browsers initially, being
> compatible with everything is going to be a lot work or too limiting anyway.
>

It's not very important in activities but I think the framework should be
compatible with a large number of browsers. Today two activities have
compatibility issue (Clock), other issues are in the framework (Custom and
Blob object).

It would be good to come up with a set of strategies to do layout on
> multiple screen sizes and document them. Manuel figured out some of that
> stuff if I remember correctly.
>

Ok cool.


> It's a way for the native python activity to pass some  initial
> environment variables to the web layer (like the activity id and the
> datastore object id). As for bus.js etc I would fork and get rid of these
> initially, then we can figure out the best way to reconcile.
>

Okay. I guessed it was use as a way to detect Sugar Linux or Sugar Web but
I didn't figure how. To hack it I've forced the creation of the sugar
object (
https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L2)
but I'm not very happy with it.

                  Lionel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131115/fb272cf6/attachment.html>


More information about the Sugar-devel mailing list