[Sugar-devel] HTML activities

[Gonzalo Odiard]

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 <cscott at laptop.org> 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
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130130/c3aabf76/attachment.html>