[webkit-dev] pyjamas-desktop / webkit / pywebkitgtk - running AJAX web apps... as a desktop app!
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Aug 29 15:32:12 PDT 2008
code references and patches:
git at github.com:lkcl/pyjamas-desktop.git
first things first: thank you to everyone on the gtk and webkit mailing
lists and irc over the past week for helping answer numerous questions,
i just wanted to let you know that, with your help, enough has been done
for me to move on to developing pyjamas-desktop properly.
(what is pyjamas-desktop?)
based on webkit, it's a cross-platform application development API.
like pygtk, like python-qt4 and wxWidgets, only much cooler because you
can, if you want, load *complete* html pages, *complete* stylesheets, and
because it's based on webkit. so you get access to the DOM model,
media plugins, CSS stylesheets - everything.
(whoaaaa - bbb..back up a bit: what's pyjamas?)
based on http://code.google.com/webkit, pyjamas is a cross-browser
_web_ application development API. it looks and smells like a desktop
API, but underneath, pyjamas is an AJAX library and a comprehensive
widget set (implemented as AJAX but you *never* go anywhere near
in short, you get to write apps that _look_ like they ought to be
running on a desktop, and pyjamas takes care of all the nasty browser
tricks that you would normally take _months_ to code up - if you
bothered at all - for safari, opera, IE7, IE6, firefox, mozilla,
.. even konqueror nearly works if you twist its arm hard enough.
(what's the fuss, then?)
pyjamas-desktop is a project to port pyjamas - the toolkit that
was ported to java - the one that looks like it _ought_ to run on
the desktop - to the desktop.
(i don't get it. so what??)
you get to run the SAME application source code (written in python)
as EITHER a web application - on 99% of browsers in use today -
OR as a desktop application - on as many environments as webkit
(well, actually, pywebkitgtk at the moment) will compile on.
effectively, pyjamas becomes a "standard" for application development.
cross-browser. cross-platform. even cross _widget_ set, if someone
wants to create pywebkitqt4 and the associated qt DOM model webkit
bindings. and a python-wxWidgets one.
(you... huh?? i'm having difficulty getting my head round the significance)
free software from ground up home-grown alternative to silverlight.
free software from ground up home-grown alternative to adobe AIR.
because, as it's web-based, being based on webkit, any media plugins
that webkit support, now and in the future, you can "embed", control,
and interact with, through the webkit API.
e.g. flash plugins.
(what else? got a kitchen sink to throw in with that?)
this isn't burger king, you can't have fries - but you _can_ have
an event sink, rather than a kitchen sink. and yes, you _can_,
through the glib-gobject bindings, access and control webkit's DOM
model through perl, *mm, or whatever obtuse language you choose.
my obtuse language of choice is python; h2defs.py / pygtk-codegen
made short work of turning the glib header files into python bindings,
and we're off.
(what's the catch?)
there is a hell of a lot left to be done - however, it shouldn't
take too long. i did a part-port of pyjamas to gtk2 in a few days -
enough to tell me that i was wasting my time ...
( http://lkcl.net/pyjamas-desktop/pygtk2.tgz if anyone's interested)
.. due to the lack of support for libgtkhtml3 which has a crucial
feature i needed. i did a part-port of pyjamas to qt4 in about _two_
days... (http://lkcl.net/pyjamas-desktop/pyqt4.tgz if anyone's
interested) ... enough to know that, despite the rich-text support,
the layout mechanism in Qt, and the lack of support for being able
to remove layouts from grid layouts.... i just... gave up and made
a beeline for webkit...
the point is: once i had pywebkitgtk working, it's only been three
hours and i have the Mail.py example almost fully working already!
(what's the other possibilities?)
there exists some _really_ exciting tantalising possibilities with
this, which takes a bit of explaining.
the first time i saw pyjamas, i went "cool! a web-based widget
set that looks like a desktop widget set. i wonder if it can be
_made_ to be a desktop widget set?".
then, i saw that llampies - one of the pyjamas developers - had
ported pyjamas to gtk. i got really excited, only to find that
_actually_ what he'd done was the OTHER WAY ROUND: he'd ported
_gtk_ to pyjamas!
llampies, basically, has written "wrappers" - alternative
implementations of gtk.py, glib.py and gobject.py, which get
along with your pygtk2 app, to run your pygtk2 apps UNMODIFIED
as *web* applications.
so, you write your app as a python-gtk app, you compile it up
using pyjamas, and it runs as a web application. even though
it's actually python-gtk-compliant source code.
bear with me whilst i outline why that work is so significant.
take a python-GTK application, and run it through pyjamas,
and it's a web app... but if you run it under pyjamas-desktop,
it runs ... as a web app.
(that doesn't sound significant - in fact it sounds mad.
you're taking a desktop app and running it... err... on a
desktop, adding massive overhead and missing out bits of
the pygtk2 API as well, _and_ you're limiting me to the
subset of python that the pyjamas compiler supports!!!)
whooa, hold your horses - it sounds mad... until you remember
earlier that i mentioned the possibility of running webkit
under python-qt4 if someone writes the bindings. and running
webkit under python-wxwidgets if someone does the python
bindings for that, too.
so... you get to write an app as a python-gtk2 app, conforming
to the pygtk API, and... through pyjamas-desktop/webkit with
llampie's gtk2 wrappers, you get to run your python-gtk2 app
UNMODIFIED in a qt4 environment. or a wxwidgets environment.
or... any-other-kind-of-environment. including a web app,
remember, if you dump pyjamas-desktop and just use llampie's
(it's still madness)
yeah. quit bitching about it.
oh - and you _should_ be writing your apps to conform to a MVC
framework _anyway_, so there's no need to complain about being
limited to a subset of the python library. you have JSONRPC
(yes, i've written a JSONRPC proxy, which is a useful JSONRPC
client library in its own right), you have pimentech's
JSONRPC server-side django plugin, so you can write the
front-end in a limited subset of python (it's not _that_ limited)
and get it to talk to the back-end, which happens to be running
on loopback HTTP as a twisted app or a django service, where
you have full and complete access to the entire range of python
and, then, if you're ready to make it a web app, compile it
to AJAX with pyjamas and... well... that's it. you're done.
and your code is nicely subdivided into front-end, back-end,
just the way it should be.
if you made it this far, thank you for reading. if you helped
make the glib bindings happen, thank you once again. if you
would like to see qt4 webkit DOM model bindings happen, contact
me and we'll discuss it. if the webkit glib DOM bindings prove
useful to you, financial contributions would be very welcome.
if you're not in a position to do that, your blessings and
gratitude will do just as well.
More information about the webkit-dev