<div dir="ltr">On 14 November 2013 10:03, Lionel Laské <span dir="ltr"><<a href="mailto:lionel@olpc-france.org" target="_blank">lionel@olpc-france.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Here are
the major issues I've faced building the prototype (all source code is here
[2]):
<p style="margin:0in;font-family:Calibri;font-size:11pt" lang="en-US"> </p>
<ul style="margin-left:0.375in;direction:ltr;margin-top:0in;margin-bottom:0in" type="disc"><li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-family:Calibri;font-size:11pt">Multiple copy of Sugar
Framework in each activity. My work was mostly a way to group existing
Sugar Web activities. BTW I need to upgrade a part of the Sugar Web
Framework to implement few features (Stop button, XO Colors, …). This
upgrade concern today the bus.js file (most of the hack is here [3]) but
this file is copied in each web activities :-( So I had to upgrade this
file in each activity directory. I think we must find a way to allow the
Sugar Web Framework to be deployed/referenced one time only.</span></li></ul></div></blockquote><div><br></div>You could put them outside the activities directory and change the loader.js to look there.<br><br>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.<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">Consider if you really want all the activities to always use the latest version of the library. When you make an API change you will need to fix all of them. Volo makes it pretty easy to update the local library copy, I'm not sure we really need a global library here.<br>
</div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ul style="margin-left:0.375in;direction:ltr;margin-top:0in;margin-bottom:0in" type="disc">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-family:Calibri;font-size:11pt">Server side stuff. Today the
Sugar Web Framework use Web Sockets to communicate with the system layer.
It's good when running on Sugar but it's not a good idea in a Web-Browser
only world because you can't have a process to listen Web Sockets. I think
we should imagine a way to have a Sugar Web Framework that could work in
stand-alone mode (without any server side). For example by using directly
LocalStorage instead of waiting for a bus call. It's what I've done to
retrieve xocolor [6]</span></li></ul></div></blockquote><div><br><br></div><div>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).<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ul style="margin-left:0.375in;direction:ltr;margin-top:0in;margin-bottom:0in" type="disc">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle"><span style="font-family:Calibri;font-size:11pt" lang="en-US">HTML5
compatibility issues. Running existing Sugar Web Activities on tablets (XO
Tablet and Samsung GalaxyTab) raise some issues regarding HTML5
compatibility. Specifically some features (CustomEvent object, Blob
object, </span><span style="font-family:Calibri;font-size:11pt" lang="fr">window.webkitRequestAnimationFrame,
…) </span><span style="font-family:Calibri;font-size:11pt" lang="en-US">used
by the framework or by activities don't work everywhere due to WebKit
compatibility. I think we should isolate these features (or avoid using
it).</span></li></ul></div></blockquote><div><br></div><div>Yeah or use them conditionally.<br><br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ul style="margin-left:0.375in;direction:ltr;margin-top:0in;margin-bottom:0in" type="disc">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle"><span style="font-family:Calibri;font-size:11pt" lang="en-US"> Of course one another major issue is that the screen size could be
very different from a device to another. Unfortunately activities are
often linked to the XO screen size.</span></li></ul></div></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ul style="margin-left:0.375in;direction:ltr;margin-top:0in;margin-bottom:0in" type="disc">
<li style="margin-top:0px;margin-bottom:0px;vertical-align:middle" lang="en-US"><span style="font-family:Calibri;font-size:11pt">Environment. The Sugar Web
Framework use an environment object (env.js), it seems to be used to
detect the current platform but that I don't understand exactly how it
works. Any explication regarding this point will be appreciate.</span> <br></li></ul></div></blockquote><div><br></div><div>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.<br>
</div>
</div></div></div>