On 22 June 2011 12:54, Marco Pesenti Gritti <ma...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel