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.


Why do not you implement the new Browse in C/C++?
It would have three advantages:
1. It could reuse an existing WebKit browser's code.
2. It would not depend on incomplete/unmaintained python bindings.
3. It would be fast. At least it would not use 60M of python runtime memory per process. Of course it would require reimplementing some simple toolbar and children would not be able to look into the browser's codebase (only though the web) but I think it would be an interesting option to consider. At least the 3. point could be important enough for the most used application in Sugar...
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to