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

[Lucian Branescu]

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).

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.

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).

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.

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
>>
>
>