[Sugar-devel] [Sugar-Devel] Sugar Web Engine
lucian.branescu at gmail.com
Fri Jun 18 08:01:05 EDT 2010
After much trouble getting hulahop & xpcom to work in the abstraction
layer webwrap, I've decided to drop it and focus on pywebkitgtk. To
this end, yesterday I got Browse to start and load pages with
pywebkitgtk, but with several features disabled. I'll be working on
getting all of Browse's features to work with pywebkitgtk.
I've also looked at webkitgtk+'s API and I'm confident that switching
to PyGI will be quite easy, mostly just renaming things.
On 16 June 2010 11:48, Lucian Branescu <lucian.branescu at gmail.com> wrote:
> Unfortunately, that doesn't solve any of my problems.
> I would gladly drop hulahop entirely (it's a mess and very low-level), but
> several people have expressed concern that gecko might be a better choice
> long-term. However, I have not been able to confirm any of their performance
> concerns. In my tests, gecko always used more memory and was much slower
> than webkit. Also, xulrunner is made first for firefox and second for
> embedding, and it shows painfully.
> On the other hand, I can't decide by myself to use PyGI since it's too
> experimental for a platform's main browser and the rest of Sugar doesn't use
> it. However, the API of pywebkitgtk would be similar to webkitgtk+PyGI, so
> switching later on shouldn't be very hard. Especially since pywebkitgtk's
> author himself already did it.
> Because of various hulahop & xpcom quirks, webwrap (the abstraction layer)
> is proving increasingly hard to write. I will give it a few more days, but
> if I can't figure out a clean way to wrab both hulahop and pywebkitgtk I'll
> drop hulahop entirely and let any future switching back to hulahop rely on
> On 16 Jun 2010 11:07, "Tomeu Vizoso" <tomeu at sugarlabs.org> wrote:
> On Sun, Jun 6, 2010 at 15:33, Lucian Branescu <lucian.branescu at gmail.com>
>> I've received eve...
> Just wanted to make sure you know that the pywebkitgtk+ maintainer
> recommends using PyGI instead:
> That was written in January and since then PyGI has progressed greatly.
> I personally think that you should have less concerns than other
> people that are moving to PyGI right now.
> As a general remark, I don't think it's a good idea to cling to
> software modules whose authors are so willing to drop down and will be
> less painful in the medium term if people start moving now.
> That said, it hasn't been decided yet that Sugar will depend on PyGI
> from 0.90 on (see a new thread from today).
>> Since it's already late into the project, unless someone has a better
>> idea, I'll stick to fully...
More information about the Sugar-devel