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.subz...@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 <br...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel