Hi Scott, Any reason to prefer Firefox over Webkit? I ask because we ported Browse to webkit, we had a lot of issues in the past using Gecko. I am curious too about if you has tested different libraries to use the html canvas. Other than that, I agree in the main ideas you shared.
Gonzalo On Wed, Jan 30, 2013 at 1:35 PM, C. Scott Ananian <[email protected]> wrote: > At the risk of diverting you guys from your good work, let me add a few > related thoughts: > > 1) I think the core of this "new API" focus should be on the question: > "what are the essential parts of the Sugar experience"? I would like these > roughly as follows (you may have other ideas): > a) the journal > b) collaboration > c) consistent look and feel ("visual design language") / toolbar, etc > d) "view source" > e) polyglot support > > First, decide among yourselves what the "core sugar experience" is. Then > I would encourage the creation of separate focused APIs / libraries for > these main components, not rolling them all together into a big "sugar" > tarball. That way apps which want (say) just the sugar look and feel can > import a package which does "just the UI widgets" without dragging in other > stuff (and even before, say, collaboration is finished). > > These APIs should be written in a language-independent manner (think about > gobject) so that the same basic APIs can be used on multiple platforms. > This will make it easier to write a "sugar activity" (meaning support for > a-e) which is Android-native, or (my preference) a web activity which > supports a-e on a desktop web browser, an xo running sugar, and an android > device. > > 2) Ideally these libraries would all be optional; that is, there is a > "pure web" implementation/fallback available, which is overridden when > there is platform-specific support. I should be able to run a sugar > activity on a desktop web browser, but I might not get (for example) > journal support -- or the journal support will be via a > journal.sugarlabs.org server somewhere. If I run the same web activity > on an XO, there are local hooks (think "a plugin") that allows me to use > the "real" journal. If I run the same activity on an Android phone, the > plugin might use a special Android implementation of the journal. Write > good APIs, and allow multiple implementations. > > 3) I think embedding a web server is probably the wrong way to go. HTML5 > has robust offline application support. If you write an offline web app, > it runs the same on an XO, a desktop browser, and an android phone. I > recommend Firefox/Android for running webapps on Android. The Nell's > Balloons and Nell's Colors activities I've written are good examples of > offline web apps; there's also an offline Wikipedia reader. The > interesting technical challenge is to prepopulate the offline web cache > with the appropriate files when the activity is installed, but this is > pretty straightforward profile hacking; I can tell you how I do it for > Firefox/Android if there is interest. > > 4) I recommend adoption of a component strategy. Something like > https://github.com/component/component/wiki/Components although jamjs.organd > volojs.org also look very reasonable. But try to keep dependencies > lightweight. You want just enough to provide for good namespacing. > > 5) I have written a plugin for Firefox/Android which allows access to > Android' native Java APIs from web app code. This is a good way to > implement (for example) a collaboration API on top of Android's native > peer-to-peer wifi APIs. I'm interested in working on this. > > 6) The webkit web inspector is the best implementation of "view source" > that I have yet seen. Try to find ways to leverage that --- ie, avoid > packaging strategies that bundle or obfuscate the code. I believe this is > also the strongest argument against the use of CoffeeScript for Sugar, at > least at the library level. (The "source map" feature of webkit helps to > some degree, but it's still not as clear as viewing straight java script.) > > 7) Writing fluent javascript isn't about syntax, believe it or not. You > can get most of the "good stuff" via good use of the native methods. For > example, Array.forEach is an excellent substitute for "for each" syntax. > In fact, I've done quite well writing in a deliberate *subset* of > Javascript (see http://cscott.net/Projects/TurtleScript/) in an effort to > make my code easier to understand and visualize using block-based editors. > That said, I expect 90% of your work will be writing good interfaces and > APIs. If this is done, it will be easy to write clean readable activities > on top of the APIs, even if the actual implementation of some of the APIs > gets messy. > > Hope this is helpful. I think it would actually be useful to have a > summit of some sorts around these issues. As you can tell from the above, > I believe that a good implementation of web activities for Sugar is also > important for the continuation of the Sugar ideas on other platforms, like > desktop and android. So this is good fundamental work. It's good to see > how much progress you guys have already made. > --scott > > -- > ( http://cscott.net ) > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > >
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
