[Sugar-devel] webkit, hulahop; developing apps using browser engine DOM for widgets

[Luke Kenneth Casson Leighton]

On 6/10/09, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> Hi Luke,

 hii tomeu

>  > 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:
>
>  http://blog.tomeuvizoso.net/2009/01/embedding-mozilla.html
>  http://blog.tomeuvizoso.net/2009/01/galeon-and-learning.html

 i tell ya - it's _just_ not getting picked up, because it's very
difficult for people to conceptualise this stuff [oh?  web browser?
that's javascript only, right?  huh?  what do you _mean_ W3C DOM can
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
>  maintained.

 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:
>
>  http://git.sugarlabs.org/projects/browse/repos/mainline/blobs/master/progresslistener.py

 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.

ok.


> 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
the fact that pyjamas apps can be compiled to javascript, to run in
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
XMLHTTPRequest functionality.

so yeah - you get that total app agnosticity, browser independence,
total widget set agnosticity - but you _have_ to subdivide the app as
MVC.

one key advantage you get of making the apps browser-capable in this
way is that you automatically get that "thin client" capability
(albeit, because you'd be running monster amounts of javascript it
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
compiled to javascript) served up to much less capable or even
_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
javascript environment:

  http://code.google.com/p/pyjamas/wiki/GsocLlpamies

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.

l.