<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/15 Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span><br><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">You could put them outside the activities directory and change the loader.js to look there.<br><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote><div><br></div><div>Nice. I didn't know this require feature.<br>
 <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"><div class="gmail_extra"><div class="gmail_quote">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></div></blockquote><div><br></div><div>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. <br>
 <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"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote">
<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></div></div></blockquote><div><br></div><div>Hummm. I would be better to avoid forking now. At worse, I think, a testing condition (if Linux else Web/Android) could be better.<br><br><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"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div class="im"><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></div></blockquote><div><br></div><div>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).<br>
<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"><div class="gmail_extra"><div class="gmail_quote"><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><div><br>
</div><div>Ok cool.<br> <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"><div class="gmail_extra"><div class="gmail_quote">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></blockquote><div><br></div><div>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 (<a href="https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L2">https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L2</a>) but I'm not very happy with it.<br>
<br></div><div>                  Lionel.<br></div></div><br></div></div>