[Sugar-devel] Browse and the move to WebKit

[Daniel Drake]

On 22 June 2011 12:54, Marco Pesenti Gritti <marco at marcopg.org> wrote:
> I'm not sure. I think hulahop in principle is pretty much equivalent
> to WebKitGtk + PyGi. In practice though I suspect there are going to
> be differences on the amount of code required to write something like
> Wikipedia and Help. If it's too much, people will just cut/paste the
> whole Browse, which I think we should avoid.
>
> The way I would approach it, is to first port Browse basing it
> directly on WebKitGtk. Then port Help or Wikipedia and see if it make
> sense to share code. If it's generic enough to be upstreamed we should
> try to. If it's sugar specific, adding it to sugar-toolkit would
> probably make sense (a common toolbar implementation for example?).

Thanks for your input on this. I've summarised all the collected info
so far here:
http://wiki.sugarlabs.org/go/Features/WebKit

The biggest finding that came from outside this thread is that if
Browse is to move to pygi to access webkit, the Sugar python bits that
it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So
we have a prerequisite on sugar (or at least parts of it?) being moved
to gtk3/pygi first.

> The hardest case are activities which implement their content view in
> html and the rest using native widgets. Just some thoughts:

I think this is exciting and definitely a good area to explore, but at
this point I'm trying to keep it separate from the "rescue Browse"
operation. I outlined the reasoning here:
http://wiki.sugarlabs.org/go/Features/WebKit

Thanks!
Daniel