Current Release: 0.8alpha1
This is the 0.8alpha1 release of Pyjamas. Pyjamas comprises several projects,
include a Graphical Widget Toolkit, such that pyjamas applications can run
or stand-alone on the desktop (as a competitor to PyGTK2 and PyQT4).
compiler and associated modules include:
* behaviour more like python, including sys.exc_info and tb_frame.f_globals,
a basic traceback module, class creation using __class__ on the base,
__delattr__ support, __setattr__ support and assignment to slices in lists.
* further changes to pyjsbuild to make it more equivalent to gcc and Make.
In the User-Interface suite, which is separate from the Pyjamas
* Enabling of asynchronous module loading (previously present in the 0.5
* Adding HTML5-compliant drag-and-drop support (both native as well as
emulated, so that older browsers appear to have HTML5-style drag-and-drop)
* Fixing a long-standing bug with DialogBox (still present in GWT) related
to mouse events being lost.
* Addition of an "auto-build" option - based on file-monitoring - to pyjsbuild
* Addition of oninput and onpropertychange event support, as well as
Pyjamas is a port of Google Web Toolkit to Python, and thus enables
the development of Rich Media AJAX applications in Python, with no
need for special browser plugins. Pyjamas contains a stand-alone
very similar to Desktop Widget Set APIs (such as PyQT4 or PyGTK2).
Pyjamas also contains a Desktop Widget Set version, running as pure
python, with four useable Desktop ports available. Using web browser
technology startlingly provides an alternative to traditional
Widget sets, such as PyQT4 and PyGTK2, with the advantage of having
full support for HTML, CSS, Plugins and other web-related features
already built-in. For the windows port, this can save users and
developers around 30mb of downloads, as MSHTML is preinstalled on
the Windows Operating System, as part of IE.
For more information, see:
Known bugs: http://code.google.com/p/pyjamas/issues
#290, #227, #228, #230, #304
Pyjamas-Desktop runs exactly the same python application on the
Desktop (as pure python).
Release 0.6 of Pyjamas incorporated Pyjamas-Desktop directly into
the Pyjamas Distribution. To use Pyjamas-Desktop there are three choices,
with more planned [MacOSX PyObjC; KDE's PyKHTML].
All ports of Pyjamas-Desktop will require a JSON library to be
installed: as there are plenty already, it is counter-productive
to write yet another one. simplejson is recommended.
1) - XULRunner
install hulahop and python-xpcom. hulahop, from OLPC SugarLabs,
is distributed with both Debian and Ubuntu; python-xpcom is part
of XULRunner and is also distributed with both Debian and Ubuntu.
Other users should investigate the installation instructions for
python-xpcom and hulahop for the operating system of their choice
on the appropriate web sites.
GNU/Linux, FreeBSD and other POSIX systems are strongly advised
to use XULRunner for Pyjamas-Desktop: it is the most stable of the
Sadly, modifications made by the Mozilla team to the xulrunner API
have not propagated through to python-xpcom due to lack of attention
and support by the Mozilla team. Until funding is made available to
keep python-xpcom up-to-date, older versions of XULRunner must be
used: versions 1.9.0 or 1.9.1 are known to be suitable.
2) - PyWebKitGtk
There are two versions of PyWebKitGTK: please do not use the older
version which has been "taken over" by the Webkit team: the Webkit
team have decided that full support of and direct-equivalent
interoperability with the full W3C HTML specifications is not important.
The version of pywebkitgtk at http://www.gnu.org/software/pythonwebkit
provides full and direct python-equivalent interoperability for all functions
Desktop will function correctly.
PyWebkitGtk must be explicitly enabled. create a $HOME/.pyjd/pyjdrc file
containing the following two lines:
3) - PyWebkitDFB
This is an experimental but minimally functional engine that is extremely
quick to start up. The build dependencies are also drastically smaller than
any of the other web browser engines (which indirectly contributes to the
fast startup time).
HTML5 is fully supported, with the exception of Video and Canvas; also
missing at present is support for Frames. Despite the present limitations,
PyWebkitDFB is highly suited to embedded systems, as well as being useable
as an excellent and ultra-quick general-purpose web browser engine.
PyWebkitDFB must be explicitly enabled. create a $HOME/.pyjd/pyjdrc file
containing the following two lines:
4) - MSHTML
For Windows users, all that's required, other than installing python
and Internet Explorer, is one further tiny package: Win32 "comtypes".
Win32 "comtypes" can be downloaded here:
Unlike the other ports, which can comprise a whopping great bundle
of anything up to 30mb in size, the MSHTML port literally requires
nothing more than comtypes, thanks to the far-sighted design of the
MSHTML Trident Engine and its extensive COM interface.
5) - PyQt4
Kindly contributed by Thomas Henning, the PyQT4 port requires a current
PyQt-snapshot with Qt 4.6 (which includes QWebElement, a DOM-like API for
The PyQt4 engine is highly experimental, and requires a configuration file
to explicitly enable it. create a $HOME/.pyjd/pyjdrc file containing the
following two lines:
Sadly, the PyQT4 port serves more as a demonstration of how never to access
web browser DOM functionality from python (ever). The reason is simple:
code snippets must be created on-the-fly and executed, and all incoming and
(as Qt4 objects).
Aside from providing truly dreadful performance, this technical approach
should have you either in hysterics, throwing up or requiring counselling,
depending on your resilience and constitution. All is not lost: if funding
is made available, the PythonWebkit project can, with very little actual
coding required, be ported to Qt4, as the GNU PythonWebkit Project has been
designed to provide python access to DOM functionality, independent of the
actual GUI display engine being used.
6) - PyKDE
The PyKDE engine has been done as a "thank you" to the KDE Team, without
whom Webkit would not exist. Sadly, though, for technical reasons, the PyKDE
engine requires that the entire KHTML Part be compiled with c++ "rtti" enabled,
and the majority of GNU/Linux Distributions explicitly disable RTTI due to
it having an impact on performance.
If this is ever fixed, then out of sheer nostalgia and bloody-mindedness, the
PyKDE engine will have continued support, even though the KHTML engine is only
DOM TR2 compliant (at present).