[Sugar-devel] HTML activities TODO
Hi, It was mentioned in some other thread, but posting to make sure everyone has seen it :) We have a good start of a TODO list for html activities. If you want to get involved this is your chance! https://github.com/sugarlabs/roadmap/issues/8 -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 5 February 2013 01:57, Manuel Quiñones wrote: > Now I see this WebRT is the webapprt-stub binary that is inside the > app bundles that firefox marketplace installs. > > I downloaded firefox 20 beta, started it, went to the marketplace, and > installed some apps. They are then available in gnome-shell. Behind > the scenes they install a .desktop file in > ~/.local/share/applications/ and the bundle at ~/.http* .The profile > folder is there, together with the webapprt-stub, webapp.json, > webapp.ini, profiles.ini and icon.png. Yup. I'm trying to figure out the best way to integrate with this stuff. One possible approach is to add support for these desktop files to the sugar shell. Another is to add support to firefox for installing them as sugar activities, when running inside sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 4 February 2013 20:20, Manuel Quiñones wrote: > So what the wrapper does is 1. add an addon that hides > "navigator-toolbox" and "addon-bar", and 2. call firefox with a > profile in the activity data folder and with the addon. Am I right? Yup. > I was reading about Open Web Apps and reached Desktop WebRT, which is > supposed to run an app in a chromeless browser. Could be that what we > need? Yeah. One complication is that it's not completely chromeless. There is a menubar, on linux at least. I think we can find a way to get rid of it, extensions or prefs, might require getting a patch upstream though. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
2013/2/4 Manuel Quiñones : > Hey Daniel, glad to see progress :) > > 2013/2/2 Daniel Narvaez : >> I made some good progress on this today. >> >> A bit of a write up on the approach we are taking >> >> http://sugarlabs.org/~dnarvaez/sugar-html/README.html >> >> A wrapper for firefox with an addon >> >> http://git.sugarlabs.org/sugar-html-browser/sugar-html-browser > > So what the wrapper does is 1. add an addon that hides > "navigator-toolbox" and "addon-bar", and 2. call firefox with a > profile in the activity data folder and with the addon. Am I right? > > I was reading about Open Web Apps and reached Desktop WebRT, which is > supposed to run an app in a chromeless browser. Could be that what we > need? Now I see this WebRT is the webapprt-stub binary that is inside the app bundles that firefox marketplace installs. I downloaded firefox 20 beta, started it, went to the marketplace, and installed some apps. They are then available in gnome-shell. Behind the scenes they install a .desktop file in ~/.local/share/applications/ and the bundle at ~/.http* .The profile folder is there, together with the webapprt-stub, webapp.json, webapp.ini, profiles.ini and icon.png. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
2013/2/2 Daniel Narvaez : > A demo activity > > http://git.sugarlabs.org/sugar-html-demo I see the demo bundles require.js . But isn't require part of CommonJS? I mean, isn't this already there in JS? http://wiki.commonjs.org/wiki/Modules/1.1 -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
Hey Daniel, glad to see progress :) 2013/2/2 Daniel Narvaez : > I made some good progress on this today. > > A bit of a write up on the approach we are taking > > http://sugarlabs.org/~dnarvaez/sugar-html/README.html > > A wrapper for firefox with an addon > > http://git.sugarlabs.org/sugar-html-browser/sugar-html-browser So what the wrapper does is 1. add an addon that hides "navigator-toolbox" and "addon-bar", and 2. call firefox with a profile in the activity data folder and with the addon. Am I right? I was reading about Open Web Apps and reached Desktop WebRT, which is supposed to run an app in a chromeless browser. Could be that what we need? -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 1 February 2013 07:36, C. Scott Ananian wrote: > It's actually not very hard: Firefox implements a new profile directory for > every installed web app. We just install the webapp once on-line, and then > tar up the profile directory. Installing the app offline is just untarring > the profile directory and tweaking the .js file which tells firefox which > profiles/webapps it has. Firefox should have better mechanisms for this in > the future; http://mozbugs.github.cscott.net/ lists some bugzilla bugs > tracking useful features in this regard (for example > https://bugzilla.mozilla.org/show_bug.cgi?id=790456 ) -- but you don't have > to wait for upstream, you can make it work now. Are you running the applications using firefox or webapprt-stub? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
I made some good progress on this today. A bit of a write up on the approach we are taking http://sugarlabs.org/~dnarvaez/sugar-html/README.html A wrapper for firefox with an addon http://git.sugarlabs.org/sugar-html-browser/sugar-html-browser A volo sugar-activity library, exposing activity.close() http://git.sugarlabs.org/sugar-html-activity A demo activity http://git.sugarlabs.org/sugar-html-demo Putting all of this together we get an hello world activity running in sugar :) The close button doesn't work yet, eh. As usual if you want to play with it git clone git://git.sugarlabs.org/sugar-build/sugar-build git checkout html make run ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 02/01/2013 02:08 PM, Gonzalo Odiard wrote: With technologies like HTML5 and EPUB3, the lines between a book and a activity start to blur. (EPUB2 prohibited the use of javascript, but is allowed in EPUB3) A nice example of a book with dynamic content is http://natureofcode.com/book/chapter-1-vectors/ The technology behind will be the same, we need think about what is better in every case, how can we improve the tools to create the books or activities, and how the users can improve, comment, and share/communicate, changing from a read-only experience to a read-write use, like in a wiki. Gonzalo The last sentence is the essential point here: 'create' and 'consume'. I especially put 'create' here first. One of the most important paradigms of Sugar :) Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
With technologies like HTML5 and EPUB3, the lines between a book and a activity start to blur. (EPUB2 prohibited the use of javascript, but is allowed in EPUB3) A nice example of a book with dynamic content is http://natureofcode.com/book/chapter-1-vectors/ The technology behind will be the same, we need think about what is better in every case, how can we improve the tools to create the books or activities, and how the users can improve, comment, and share/communicate, changing from a read-only experience to a read-write use, like in a wiki. Gonzalo On Thu, Jan 31, 2013 at 10:41 PM, Edward Mokurai Cherlin < moku...@sugarlabs.org> wrote: > On Wed, January 30, 2013 4:26 pm, lio...@olpc-france.org wrote: > > > >> * What we are doing here is still heavily experimental. I don't think we > > know exactly where we are going yet, just trying to find out. I posted on > > the list so early > >> because I think it's important to get feedback. > > Quite right. Let me add a question, then, where I would like to get > some feedback. One of the ideas at the foundation of the Sugar Labs > program for Replacing Textbooks (with OERs) is to be able to write > learning materials using tools such as HTML5 or EPUB3 in a way that > would allow us to embed and script Sugar activities. This would make > it straightforward to implement a curriculum fully integrated with > Sugar. (We could also discuss what other Sugar activities would be > needed for the purpose, and whether existing Sugar activities would > need to be adapted to make all of this work.) > > Do we know how to do such a thing in HTML5? What other questions do we > need to ask in order to start looking for more answers? > > >>* I think we have a bit of a different perspective. It seems like the > >> goal > > of your framework is to add the ability to write html activities for the > > sugar platform, possibly > >> mixing with python code. > > > > Okay. But it's interesting to have a look on today and tomorrow at the > > same > > time. > > So, my idea is to see how HTML activities developed today could work (or > > could be easily adapted) tomorrow. > > > > > >> We also have that goal but, in addition, we would like to provide the > > ability to write fully cross-platform activities. That could run for > > example > > on Android, on iOS, or > >> inside a web browser. So we are talking about a toolkit which is > > completely independent from the gtk3 one. > > > > It make sense. > > > > > * Toolbar widget using the icons API, perhaps without palettes. > >>> > >>> Yes but we should allow developers to use a true Python toolbar > >>> instead of the simple one when needed. > >> > >> I'm going back and forward on this. Of course I see why it's a required > > feature from your point of view... But if we provide an html toolbar > > implementation with all the > >> features of the gtk one, why would developers use the gtk one for an > >> html > > activity? Maybe as an intermediate point while migrating from python to > > html, but I can't > >> think of other reasons. > > > > Right. > > > >>> * Datastore saving and loading. > >> > > > >> Again a lot of back an forward on this. I initially thought to implement > > those API with client side message passing (taking inspiration from your > > work). Then I've seen it's > >> implemented using the console-message signal, which doesn't really feel > > right. > > > > You're right, using "console-message" is not a perfect solution. But > > coupled > > with JSON serialization, it's a really easy way to ensure communication > > from > > JavaScript to Python (communication from Python to JavaScript use the > > WebView method "execute-script"). > > To be honest, I didn't find another way to do that. I wonder if there is > a > > better way, for example what is the PhoneGap way to do this. > > > >> I think it's a functionality that might make sense to add to webkit gtk > >> in > > a cleaner way but... I'm not sure it's worth if we have a server running > > anyway. It adds one more > >> requirement for the rendering engine we are using. Also it would be > >> pretty > > nice to the have the whole sugar-toolkit-html implemented in javascript, > > rather than mixing > >> with python. > > > > Yes but porting Gtk is a huge amount of work. > > > >> And nodejs allows us to do that. The downside of course is the overhead > >> of > > out process http communication. > > > > And adding nodejs add one more complexity. > > > > > >> I disagree on this. I think Sugar visual design is one if it's strong > > points and it should be retained. I also think all the activities should > > have a consistent visual appearance. > > > > There is no so much control in Sugar. Plus, most activities are graphical > > activities so, most activities use very few widgets. May be it could be > > sufficient to just give some guidelines about UI: do rounded button, use > a > > specific font, ... Using these guidelines it will be easy for developers > > to > > be consist
Re: [Sugar-devel] HTML activities
On Thu, Jan 31, 2013 at 8:41 PM, Edward Mokurai Cherlin < moku...@sugarlabs.org> wrote: > On Wed, January 30, 2013 4:26 pm, lio...@olpc-france.org wrote: > > > >> * What we are doing here is still heavily experimental. I don't think we > > know exactly where we are going yet, just trying to find out. I posted on > > the list so early > >> because I think it's important to get feedback. > > Quite right. Let me add a question, then, where I would like to get > some feedback. One of the ideas at the foundation of the Sugar Labs > program for Replacing Textbooks (with OERs) is to be able to write > learning materials using tools such as HTML5 or EPUB3 in a way that > would allow us to embed and script Sugar activities. This would make > it straightforward to implement a curriculum fully integrated with > Sugar. (We could also discuss what other Sugar activities would be > needed for the purpose, and whether existing Sugar activities would > need to be adapted to make all of this work.) > > Do we know how to do such a thing in HTML5? What other questions do we > need to ask in order to start looking for more answers? > Yes, this would be (more) possible in a Sugar-web-app world. Questions to ask: 1) what does the UI of this text book look like? Are the sugar apps running in little windows like illustrations in the text book, or are things integrated like in the Active Essay work by vpri ( http://tinlizzie.org/jstile/#Tutorial). 2) how are examples integrated? One of my old UI designs was that Pippy examples (for instance) would show up in your journal as Pippy things shared by Chris Ball (for instance). Do you want to mush author-generated and user-generated content together, separate them only as having been created by different people, or enforce a more rigid separation between textbook example and student work? 3) how are exercises integrated in the text? Do you want to do an active learning thing where the student has to work an exercise before they can proceed to the next chapter of the book? http://cscott.net/Publications/OLPC/idc2012.pdf describes an alternative where the "textbook" is a story (or collection of stories) told using sugar activities. My Nell paper contains a pretty complete design for one way to build an active learning system which integrates pedagogy and activities. The Active Essay work done by vpri is another way, more textbook-like. There are undoubtedly other ways as well. But the technology is basically there, once you figure out how you want it all to work. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Thu, Jan 31, 2013 at 2:00 PM, Daniel Narvaez wrote: > * Both firefox and chrome extensions have good messaging mechanisms > between content and extension that we could use. We would have the > issue to turn a full browser into a chromeless sugar activity though. > For what it's worth, I believe the above is the best strategy. You don't really want to maintaining your own fork/embedding of webkit forever. I have packaged full Firefox for Sugar in the past, there were no obvious blockers there (http://wiki.laptop.org/go/Firefox/Obsolete) and this is the path which will be best supported upstream. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Wed, January 30, 2013 4:26 pm, lio...@olpc-france.org wrote: > >> * What we are doing here is still heavily experimental. I don't think we > know exactly where we are going yet, just trying to find out. I posted on > the list so early >> because I think it's important to get feedback. Quite right. Let me add a question, then, where I would like to get some feedback. One of the ideas at the foundation of the Sugar Labs program for Replacing Textbooks (with OERs) is to be able to write learning materials using tools such as HTML5 or EPUB3 in a way that would allow us to embed and script Sugar activities. This would make it straightforward to implement a curriculum fully integrated with Sugar. (We could also discuss what other Sugar activities would be needed for the purpose, and whether existing Sugar activities would need to be adapted to make all of this work.) Do we know how to do such a thing in HTML5? What other questions do we need to ask in order to start looking for more answers? >>* I think we have a bit of a different perspective. It seems like the >> goal > of your framework is to add the ability to write html activities for the > sugar platform, possibly >> mixing with python code. > > Okay. But it's interesting to have a look on today and tomorrow at the > same > time. > So, my idea is to see how HTML activities developed today could work (or > could be easily adapted) tomorrow. > > >> We also have that goal but, in addition, we would like to provide the > ability to write fully cross-platform activities. That could run for > example > on Android, on iOS, or >> inside a web browser. So we are talking about a toolkit which is > completely independent from the gtk3 one. > > It make sense. > > * Toolbar widget using the icons API, perhaps without palettes. >>> >>> Yes but we should allow developers to use a true Python toolbar >>> instead of the simple one when needed. >> >> I'm going back and forward on this. Of course I see why it's a required > feature from your point of view... But if we provide an html toolbar > implementation with all the >> features of the gtk one, why would developers use the gtk one for an >> html > activity? Maybe as an intermediate point while migrating from python to > html, but I can't >> think of other reasons. > > Right. > >>> * Datastore saving and loading. >> > >> Again a lot of back an forward on this. I initially thought to implement > those API with client side message passing (taking inspiration from your > work). Then I've seen it's >> implemented using the console-message signal, which doesn't really feel > right. > > You're right, using "console-message" is not a perfect solution. But > coupled > with JSON serialization, it's a really easy way to ensure communication > from > JavaScript to Python (communication from Python to JavaScript use the > WebView method "execute-script"). > To be honest, I didn't find another way to do that. I wonder if there is a > better way, for example what is the PhoneGap way to do this. > >> I think it's a functionality that might make sense to add to webkit gtk >> in > a cleaner way but... I'm not sure it's worth if we have a server running > anyway. It adds one more >> requirement for the rendering engine we are using. Also it would be >> pretty > nice to the have the whole sugar-toolkit-html implemented in javascript, > rather than mixing >> with python. > > Yes but porting Gtk is a huge amount of work. > >> And nodejs allows us to do that. The downside of course is the overhead >> of > out process http communication. > > And adding nodejs add one more complexity. > > >> I disagree on this. I think Sugar visual design is one if it's strong > points and it should be retained. I also think all the activities should > have a consistent visual appearance. > > There is no so much control in Sugar. Plus, most activities are graphical > activities so, most activities use very few widgets. May be it could be > sufficient to just give some guidelines about UI: do rounded button, use a > specific font, ... Using these guidelines it will be easy for developers > to > be consistent with any JavaScript framework. > > >> While it's not required I think a system wide html server is a good >> idea. > It gives more flexibility than using file://. I really need to articulate > this better (in my mind too) >> but for example I would like to provide system icons by just specifying > them as a path. > > Yes you're right but adding a HTTP server just to share icons is very > expansive! > > >> Thanks! > > Thanks to you. I'm happy to contribute. > > Lionel. -- Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://wiki.sugarlabs.org/go/Replacing_Textbooks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 30 January 2013 20:36, C. Scott Ananian wrote: > If you wanted to be extreme about this, you'd write all your APIs in C, and > use gobject bindings (or alternative implementations carefully written to > export the same interfaces as gobject would use for the C API). But I think > Java is actually a better API-description language for the platforms likely > to be useful for this generation of Sugar. (Note that I've already > implemented the Java-to-JavaScript bridge for the Android side, so you'd > probably just write a single implementation of the APIs in Java for both > Android-native activities and Web activities on Android. You've got a > number of different options for the Sugar implementation, but if you wrote > as much as possible in JavaScript (and where necessary, C) you could reuse > that code in a plugin for desktop browsers running in gnome, which might be > convenient for development and some deployments. Many interesting behaviors > on the Sugar side are just dbus calls, and you ought to be able to trigger > those from JavaScript.) I spent some time looking into this today and I couldn't find an approach I'm fully happy with. * webkitgtk-with-webkit1 allows access to the DOM, so we could register an handler to listen for dispatchEvent calls. Unfortunately add_event_listener has broken introspection so it's not working from python. But the real problem is that this approach will not be possible with webkit2. * In webkit2 the only way to communicate with javascript/DOM is InjectedBundle, because of the multi process architecture. InjectedBundle seems a bit dubious, I've seen a mail by a core hacker dissuggesting it to the qt guys because it was designed for testing. Now both qt and gtk are using it at least internally so things might be changed, but it's hard to say given that it's completely undocumented. Anyway if we wanted to take this approach, we would basically implement an extension library which would listen to messages from the DOM and turn them into dbus calls. Probably we could also add javascript methods if we wanted instead of messages. It needs to be out of process so calling pygobject directly would not be an option. * Both firefox and chrome extensions have good messaging mechanisms between content and extension that we could use. We would have the issue to turn a full browser into a chromeless sugar activity though. * Another possible approach is what people are doing on iOS. javascript -> native code is done by making requests to a custom protocol, say message://datastore_save/json_encoded_arguments. native code -> javascript uses stringByEvaluationgJavaScriptFromString. Should be easy to code, feels a bit hacky. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 30 January 2013 17:35, C. Scott Ananian 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
Yeah I pretty much agree about a-d like, I suspect, a lot of people on
this list. I'd probably move b a bit higher, but not quite sure where.
I have never thought about e.
> 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).
Yeah, influenced also by my recent nodejs hacking, I think extreme
modularity here is a good idea.
> 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.
I still need to think it all through, but with the more detailed
explanation in the other email, I like the basic concept.
> 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.
I like the idea of a full fallback implementation a lot. Do you have
any idea on how to implement the fall back mechanism? Anything better
than
some_lib_method || document.write('