[Sugar-devel] HTML activities

Edward Mokurai Cherlin mokurai at sugarlabs.org
Thu Jan 31 20:41:34 EST 2013

On Wed, January 30, 2013 4:26 pm, lionel at 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.

More information about the Sugar-devel mailing list