[Sugar-devel] Gecko for Win32, pyjamas-desktop, python-hulahop
lucian.branescu at gmail.com
Fri Jul 3 08:43:23 EDT 2009
I'm afraid you misread my proposal. I'm making a SSB for sugar, akin
to Fluid (http://fluidapp.com) and Mozilla Prism. This would allow web
applications to work nicely in Sugar as separate activities
(applications). Stuff like userstyles, userscripts,
Sugar integration, making web apps seem even more like native
activities. In fact I should stop using 'would', because creating SSBs
works! Userstyles and userscripts will come soon.
In general, people are trying to get web stuff to work nicely in Sugar
and http://karmaproject.wordpress.com/), not the other way around.
Mostly because loads more people know flash/html+js than Python.
Of course, efforts going the other way are more than welcome, but they
have less impact in the short term.
2009/7/3 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
> 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
> 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
> 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
> 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! :)
More information about the Sugar-devel