[Sugar-devel] Gecko for Win32, pyjamas-desktop, python-hulahop

[Luke Kenneth Casson Leighton]

On 7/3/09, Lucian Branescu <lucian.branescu at gmail.com> wrote:
> 2) That was my backup proposal in fact, and I ended up getting
>  accepted with this one http://wiki.sugarlabs.org/go/Webified

 ooo.  ah.  take a look at pygtkweb (in pyjamas) and note that luis
pamirez solved the "import <pythonmodule>" problem by using JSONRPC
exactly as you outline.

however what he did was provide a way to run pygtk apps in a web
browser (unmodified) and i'm not quite sure that that's the same thing
that you're proposing in Webified.... but i'm sure there's quite a lot
of crossover.

luis only had about 8 weeks so he only got up to rangewidgets.py pygtk
example, which is still a heck of a long way.

but - the principle, it shows that it's perfectly possible to port a
python-based Widget GUI API to run in web browsers, using the pyjamas
compiler.

much of luis' work was to improve the pyjs compiler at the time: if
what you are proposing is to port the Sugar GUI API to the web then,
because luis already created browser.py and also because pyjs compiler
is much more mature, you should get a heck of a long way further.

plus, because Sugar GUI still relies on pygtk in a lot of places you
can leverage his work.

... that's if i have translated your proposal correctly as being "make
Sugar apps run (unmodified) in web browsers".

if you decide not to go "generic web browser" and instead decide to go
"browser engine" e.g. pywebkitgtk or e.g.
gecko/xul/python-xpcom/hulahop then you should definitely look at
pyjamas-desktop and _still_ look at making luis pygtkweb work run in
pyjamas-desktop!

yes, i know - that's a port of gtk to pyjamas where pyjamas runs on
top of gtk.  crazy idea but it's because pyjamas API is an abstraction
layer where one of the lower layers _happens_ to be gtk at the moment.

so, lots of options and opportunities.

>  I'd still like to make browse Browse able to use webkit (and
>  preferably to be able to switch between webkit and gecko), but that's
>  for after GSoC. I'll probably love that wrapper script :)

 yehh - take a look in pyjamas at pyjd/pywebkitgtk.py and also in
pyjd/hula.py they are near-identical.  a wrapper (submitted as a patch
to pywebkitgtk, #13) wraps the [stupid] glib/gobject naming convention
making it look like proper W3C DOM functions and thus near-identical
to xpcom.

 so in that way you are independent of the underlying DOM technology.
unfortunately, python-khtml is broken (c++ RTTI related bug and a bug
in kde's twine python-c++ auto-generator) but if it wasn't it could be
added as the third option.  macos pyobjc is the fourth option to be
considered.

in this way, you can see that if Sugar apps are based on DOM
technology (indirectly) you have maaany more options.  and if you look
at the list of dependencies to e.g. get python-hulahop compiled for
Win32, you _really_ want to open up the options much much more, by
making Sugar apps run in web browsers and on web engine technology,
rather than try to hit heads against brick walls compiling xulrunner,
python-xpcom 40mb downloads on windows ICK! :)

l.