[Sugar-devel] webkit, hulahop; developing apps using browser engine DOM for widgets
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jun 10 06:26:18 EDT 2009
On 6/10/09, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> Hi Luke,
> > so i just wanted to ask: do you _know_ how many people have been
> > looking, for years, for python bindings to XUL? are you _aware_ how
> > powerful and how under-appreciated hulahop is? :) the mozilla mailing
> > lists and other mailing lists are stuffed with unanswered questions
> > dating back to 2006, "how do i use python-xpdom to actually _do_
> > anything???" and you guys just made it... dead-easy.
> Well, I actually blogged about this recently, though it was syndicated
> only by the sugar and gnome planets:
i tell ya - it's _just_ not getting picked up, because it's very
difficult for people to conceptualise this stuff [oh? web browser?
be accessed from other programming languages? what's a W3C, anyway,
and what does my best friend dominic have to do with it?]
and even more difficult for them to find the right search-engine
keywords to find it.
if python-hulahop was on the mozilla front page, people would start
to investigate it and go "coool".
> Would be great if more people used hulahop and even took over the
> maintenance of the project. Even more if pyxpcom was more actively
well, the thing is that pyxpcom just "works". it's a meta-project.
any extensions to XUL are, i believe, _automatically_ accessible, via
the COM interfaces. so it's not like it actually _needs_ any
"maintenance" - just the occasional kick up the backside if XUL /
Gecko itself undergoes a major overhaul (unlikely).
and i believe that hulahop falls into that same category.
there's another little project like this - python-htmltmpl - which
hasn't had _any_ maintenance work done on it since 2001. reason: it
doesn't bloody need it! :) it works, it ain't broke, it does what is
needed.... yet people think that it somehow needs... maintenance.
... naah :)
> > i've created a small sample, here:
> > http://lkcl.net/pyjamas/pyjamas-xpdom.tgz
> > run python ./hula.py and it will build a web page purely using DOM
> > manipulation in python and also turn the body background green - again
> > using DOM manipulation of the body CSS stylesheet. also i think i did
> > an event click listener (ContentInvoker) because those are quite
> > tricky to get right.
> > rather painfully, i had to add a timer delay in order to let the page
> > settle down (with a blank page) otherwise the DOM isn't ready /
> > initialised - i couldn't work out any other way of doing this but i
> > understand vaguely what's going on.
> A progress listener should work, if I understand the issue correctly. See:
bing, that's it. and the Download class, too. ok - that _should_ be
it. i'm positive i tried it, but hey. will see again when i do the
pyjamas-xpdom/hulahop port. thank you.
> An check out how we attach the listener to mozilla, there's some
> weakref magic going on.
> Well, we actually started with mozilla and gtkmozembed,
oo dear :)
> and though we
> have considered adding a webkit backend at some points, nobody had the
> time to go for it to the end.
> > so - the things that were missing from webkit (decent python bindings
> > which include DOM-level manipulation) are now available, and you
> > could, conceivably, replace XUL with webkit, and still have the level
> > of functionality that is available, now (he said... :)
> What about the other mozilla stuff we use through PyXPCOM? Are there
> equivalents in Webkit for all of them?
should be (give me some examples i can check) - after all it's a
browser engine, it's supposed to be useable to create entire
fully-functioning web browsers. loading start/stop signals, console
callbacks, progress-bar signals, etc. etc.
the only significant thing that's a bit of a pain (added recently,
and imo added incomplete/incorrectly) is "open in new window" signal,
to which the new URL itself is not handed, and you _have_ to return a
new WebKitWebView from it. which is rather restrictive a design.
> > lastly i just want to emphasise that if you look at e.g.
> > pyjamas-desktop http://pyjd.org you can see that it is possible to
> > create an entire desktop widget set API on top of this browser
> > technology, that is actually independent of the browser technology
> > implementation: it doesn't matter if it's KHTML, xpdom/hulahop or
> > pywebkitgtk. and it's clear that browser technology makes for a
> > better desktop widget set API than desktop widget set APIs do. gtk
> > and qt4 are _crap_ by comparison.
> Would be interesting to have some sample Sugar activities written
> using pyjamas. That would allow us to better compare it to pygtk for
> our uses.
*sigh* - consider it to be a bit like stopping all development using
pygtk and converting everything to pyqt instead (but see right at end
- there is a possible way out)
the only reason therefore to give it really serious consideration is
all major web browsers, but you _really_ have to subdivide the
applications along MVC lines, into front-end and back-end, first,
using XMLHTTPRequest as the sole exclusive communications mechanism
between front-end and back-end.
then, if you want, you can replace the web browser with webkit (or
with python-hulahop when i've done the port of pyjamas-desktop to
hulahop) and thus run the app - unmodified - in pure python.
_including_ being able to use python DOM bindings to webkit's
so yeah - you get that total app agnosticity, browser independence,
total widget set agnosticity - but you _have_ to subdivide the app as
one key advantage you get of making the apps browser-capable in this
way is that you automatically get that "thin client" capability
wouldn't be _that_ thin - 512mb RAM minimum even with webkit).
so you'd be in a position to:
* have OLPC laptops with no hard drive at all, even only PXE
net-booted (from another OLPC laptop!)
* have one OLPC laptop be the "server" for other thin-client systems.
the back-end running on the OLPC laptop and the front-end (python
_borrowed_ machines (think 15-year-old pentium III machines)
* have one student be able to show another student or a teacher their
work, even remotely, simply by giving the other student or the teacher
the URL of their work (served from their laptop).
lastly... i _was_ going to mention a workaround - a possibility for
running gtk under pyjamas, using what luis, a gsoc 2007 student did,
which was to create a port of python-gtk2 on top of the pyjamas
but... i just saw (downloaded) sugar-graphics-toolkit, and, actually,
yaay! you have an abstraction layer, yaaay! so there is a distinct
possibility for just throwing in pyjamas-desktop underneath that.
src/sugar/graphics/*.py is only 5,500 lines total.
the MVC subdivision could be left for another time: you don't _have_
to restrict the API to use XMLHTTPRequest.
so - anyway: long answer to a short wish/question, which clearly
illustrates the level at which things could be done - not in the
actual apps (unless they too start using gtk direct) but in the core
sugar graphics API.
More information about the Sugar-devel