[Sugar-devel] HTML activities

[Daniel Narvaez]

On 28 January 2013 18:47,  <lionel at olpc-france.org> wrote:
>
> Hi Daniel,
>
> Here my suggestions experimented on my own framework [1].

Hi Lionel,

thanks a lot for the feedback. Before answering your points, it's
probably worth to point out a couple of things:

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

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

>> * Datastore saving and loading.
>
> I've already implemented it in a simple API. With two methods: "save a
> JavaScript object", "load a JavaScript object", we could probably cover 90%
> of the need.

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. 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. And nodejs allows us to do that. The downside of course is the
overhead of out process http communication.

>> * The rest of the UI widgets.
>
> Not sure to see the interest to port the UI widgets.
> HTML activities will just draw their widgets using their own framework (or
> standard HTML widget).
> Of course it will be visually different from Sugar widgets but I don't think
> it’s an issue.

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.

>> * Should we be using existing js frameworks like jquery in the toolkit ot
> limit ourselves to plain javascript.
>
> There is plenty of JavaScript frameworks. We should allow to use any
> framework to avoid losing a part of the JavaScript community.
> My current work is based on the Enyo framework but could be adapted easily
> to jQuery or to pure JavaScript.

I totally agree about allowing to use any framework. What I'm not sure
about is how to write our own widgets basically, they could be written
on top of enyo or jquery or... plain html/js.

> * How do we limit access to the http server. Can one activity access the
> files of another one?
>
> No HTTP server need in a pure HTML activity.

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.

At the moment I'm not thinking to the http server as part of the API
though, just of the sugar os implementation of it. I'd like the API to
be just client side js basically, mostly because we can't assume we
would be able to run an http server on some other OS. Might change my
mind about that in the future though :)

Thanks!

-- 
Daniel Narvaez