[Sugar-devel] ideal flash activity to be remade as karma activity

[Bryan Berry]

On Tue, 2009-03-31 at 15:45 +0200, Lucian Branescu wrote:
> Yes, I'm more interested in the slightly lower level part. As in, just
> making web apps work as native Sugar activities. I wouldn't invent any
> framework-ish thing myself as all of the framework stuff I'd use is
> already written or at least has a clear, usually proven API (HTML, JS,
> Gears, GreaseMonkey, Sugar itself).

I see Karma as being much higher-level than an API or set of tools. I
hope it will eventually become a ruby-on-rails like set of conventions
for creating a learning activity w/ stubs for the lesson plan, help
menus, and quiz section. Those are some of the long term goals for
Karma. 

In the short-term, we need to create some proof-of-concept animations w/
audio and client-side i18n. It would be great to have at the end of the
summer some re-usable javascript libraries for lesson plan reader,
navigation, help, etc.

> And I really care about adhering to web standards and practices,
> because it yields incredible code reuse and opportunities for
> integration. That's why I suggested that you could build Karma so that
> it works on (most) modern browsers, including Browse. Chrome
> experiments http://www.chromeexperiments.com/ proves that impressive
> animations and even 3D is possible with Webkit, Webkit+v8 and Firefox
> 3.1.

Absolutely, web standards make everyone's life easier

> AFAIK, there isn't any nice framework for building educational,
> interactive web apps. HTML5 (with Gears) has almost all of the
> features Flash has and JavaScript is very similar to ActionScript. If
> building stuff with Karma would be easier (or at least just
> higher-level) than doing the same with Flash, it would be a real
> incentive to stop using flash and instead use good, updated browsers
> (no IE).

AFAIK, this is true. Pretty much everyone uses flash right now and no
one shares their code.

> As for Webkit, I agree that it may be better for Sugar to switch to
> it. See my backup proposal
> http://wiki.sugarlabs.org/go/Webkit_backend_for_Hulahop
> However, Karma the way I see it should not depend on a specific
> engine. That's why I suggested making the deep Sugar integration stuff
> optional for any applications built on Karma (anything beyond saving
> HTML and Gears state in the Journal)
> 
> If there was a need for stuff built with Karma to run outside Browse
> as separate activities, a demo browser or a copy of Browse itself
> could be used.
> 
> PS: Felipe, get well soon, we need'ya!
> PPS: Again, this ended up very long and probably repetitive. Sorry.

You're doing great work Lucian! keep it up!

> 2009/3/31 Felipe López Toledo <zer.subzero at gmail.com>:
> > Hi there!
> >
> > Sorry, I've been sick :s with limited internet access, I'm updating...
> >
> > I have been talking with Bryan, we both are more interested in Karma
> > (framework), as Lucian says:
> >>On the other hand, Felipe could focus on creating an educational
> >>framework (Karma), built on standard HTML5, JavaScript and Gears. This
> >>would handle animation (preferably through <canvas> stuff), i18n
> >>(locales stored with Gears, chosen according to browser locale),
> >>general persistence (Gears & cookies), sounds (<audio>) and other
> >>things an educational framework should do.
> >
> > I think that Lucian is more interested in dbus
> >>However, the framework could have optional extensions (probably
> >>supported through a javascript-dbus bridge) that would improve
> >>integration with Sugar. These extensions would work, for example, on
> >>the runtime of my sugarizer. Web developers could improve the Sugar
> >>integration of the stuff they made with Karma and package the results
> >>as .xo bundles. Users would hardly be able to tell the difference.
> >
> >>To reduce the dependency Karma would have on my project, Browse could
> >>also have a javascript-dbus bridge and Gears added to it. Security
> >>would need to be sourted out so that only Karma web apps inside .xo
> >>bundles can access dbus
> > in this way our projects won't be mutually dependent and we can work in
> > parallel
> >
> > btw, I rise the hand to use WebKit.
> >
> > greetings.
> >
> > 2009/3/29 Bryan Berry <bryan at olenepal.org>
> >>
> >> I really like this idea. Felipe, Wadeb what do you think?
> >>
> >> On Mon, 2009-03-30 at 04:49 +0200, Lucian Branescu wrote:
> >> > There has been some talk about the interaction between my project and
> >> > Felipe's.
> >> >
> >> > I've had an interesting chat with Bryan and Ben on #sugar. Here's the
> >> > whole chat http://dl.getdropbox.com/u/317039/bryan%26bemasc%20chat.txt
> >> >
> >> > Here's the lastest idea:
> >> >
> >> > I would be focusing on building something akin to http://fluidapp.com.
> >> > I keep giving it as an example because it's very minimalist, but
> >> > provides the essential features to turn web apps into 'native' apps:
> >> > - creates independent packages of web apps from given URLs
> >> > - has Gears, so websites can be taken offline
> >> > - (optional) has userstyles to customize the look of web apps
> >> > - (optional) can customize keyboard shortcuts
> >> > - has userscripts (GreaseMonkey) to customize the behaviour (and look)
> >> > of web apps
> >> > - provides some level of platform integration
> >> > http://fluidapp.com/developer
> >> >
> >> > I'm running GMail and Google Reader and Google Docs with it and they
> >> > have mostly replaced their native counterparts because they're better
> >> > in almost every way: they work offline and sync to servers online,
> >> > they look native because of native widgets in browser engines and a
> >> > few userstyles, they're fast because everybody is focused on browser
> >> > engine performance, they have sounds and native notifications because
> >> > of userscripts+fluid APIs.
> >> >
> >> > Read my proposal for Sugar-specific details
> >> > http://wiki.sugarlabs.org/go/Webified
> >> >
> >> >
> >> >
> >> > On the other hand, Felipe could focus on creating an educational
> >> > framework (Karma), built on standard HTML5, JavaScript and Gears. This
> >> > would handle animation (preferably through <canvas> stuff), i18n
> >> > (locales stored with Gears, chosen according to browser locale),
> >> > general persistence (Gears & cookies), sounds (<audio>) and other
> >> > things an educational framework should do.
> >> >
> >> > Karma would only use technologies available in modern, HTML
> >> > 5-supporting browsers (firefox 3/3.5, safari 3/4, opera 9/10) and
> >> > Gears, which is a widely used plugin for taking stuff offline. Not
> >> > only will it work with my web app sugarizer (note to self: maybe i
> >> > should rename webified to sugarizer), but also with other browsers on
> >> > regular computers. And Browse.
> >> >
> >> > However, the framework could have optional extensions (probably
> >> > supported through a javascript-dbus bridge) that would improve
> >> > integration with Sugar. These extensions would work, for example, on
> >> > the runtime of my sugarizer. Web developers could improve the Sugar
> >> > integration of the stuff they made with Karma and package the results
> >> > as .xo bundles. Users would hardly be able to tell the difference.
> >> >
> >> > To reduce the dependency Karma would have on my project, Browse could
> >> > also have a javascript-dbus bridge and Gears added to it. Security
> >> > would need to be sourted out so that only Karma web apps inside .xo
> >> > bundles can access dbus.
> >> >
> >> >
> >> > How does that sound?
> >> > PS: Sorry it was so long.
> >> --
> >> Bryan W. Berry
> >> Technology Director
> >> OLE Nepal, http://www.olenepal.org
> >>
> >
> >
-- 
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org