Dec 24, 2010
The PyGTK team is pleased to announce the return of the highly popular all-in-one installer for Windows.
The PyGTK All-in-one installer provides an alternative installation method for PyGTK users on Windows. It bundles PyGTK, PyGObject, PyCairo, PyGtkSourceView2, PyGooCanvas, PyRsvg, the gtk+-bundle and Glade in one handy installer.
Currently 32 bit Python 2.6 and 2.7 versions are supported on Windows XP and above.
Dieter Verfaillie deserves enormous thanks for this work. Firstly, he performed the tedious job of ensuring that all the component MSI installers were exactly correct, and secondly, the really difficult task of deconstructing these individual installers and reassembling their contents into a single cohesive executable.
This is a true all-in-one installer, it does not simply call out to launch the individual MSI files.
-
More screenshots here.
-
Please file bugs as appropriate.
-
We are looking to collaborate with others who want to create gtk+ (and friends) all-in-one installers for Windows. We anticipate the tools to generate these installers will move to GNOME in future - perhaps in a common repository. Suggestions and feedback welcome.
Aug 23, 2008
Summer of Code
This has now finished, and I am really happy with how it went. I was able to complete a Python binding to libsyncml. This was done with the help of Pybindgen, which aside from a few quirks, performed admirably. Expect this to become the premier tool to automatically create python bindings to C/C++ libraries. The binding still contains too many bugs to be considered usable in Conduit trunk (read: crasher bugs) but I can see the light at the end of the tunnel.
Alexandre Rosenfeld was also successful in his Conduit Summer of Code project. He contributed audio and video support for the iPod, and a comprehensive audio/video converter/trans-coder using python-gstreamer. The iPod support seems quite comprehensive, and the converter component is a necessary component of the Conduit architecture for our future plans.
Conduit
While it may look like I have been dormant at Conduit hacking, work has been ongoing in a number of branches. Unfortunately I still cannot push these branches to bzr-playground.gnome.org because the SSH keys from GNOME have not been synced across in over two weeks, leaving me locked out.. The GIO port is now working (with the exception of gvfs bug #547133, which I would dearly like someone to commit the fix for).
One of the major tasks necessary for the GIO port was the isolation of the platform specific parts, such as GConf, and GnomeVFS. One thing that fell out of this work is that Conduit now works on Windows. With no (~10 lines) code changes. Amazing really. It should be noted that this is not actually using GIO on windows, it is using a pure Python File class implementation.
Conduit can haz Windows!
I am not really serious about maintaining this port, but it shows what is possible. If someone wants to hack on this I can point them to the necessary places. But basically you will need
I have also moved over to using PyWebkitGtk for the Conduit Web browser. They just made a 1.0 release, and I would really like it if those responsible for packaging Conduit, could please also package PyWebkitGtk, and ensure that it gets the necessary exceptions so that it is accepted into the appropriate distributions. Words cannot express how happy I am to be rid of gtkmozembed. It is a shame that webkitgtk was not accepted as an external dependency for GNOME 2.24, as this now makes getting things like pywebkitgtk into distributions a royal PITA.
Openstreetmap GPS Widget
Some time ago I mentioned the osm-gps-map widget that I have been working on, semi-related to my PhD. I just made the inaugural 0.1 release. This widget basically lets one easily write moving-map display widgets very easily, showing points of interest, and multiple gps paths atop of tiles fetched from openstreetmap, or other mapping providers. It started as a port of Tango GPS, and can now basically do everything that application did, but behind a simple GObject API. Python bindings are also provided
Miscellany
Dec 13, 2007
The Good News
Following on from my last post I have continued work on getting Jhbuild to run on windows (within msys). The basic problem which I identified in my last post was the struggle between Python (for Windows) expectations about paths, and the hoops that msys and cygwin jump through to allow unix style paths to be used. Basically os.path.join and friends do the correct thing providing the subsequent path is used within python alone. Things get all difficult when that path is then passed out to a configure script, or as an argument to a shell command. With that in mind however, a picture speaks a thousand words....
-
It works...
-
On windows...
-
Through magic....
The Status
Jhbuild is successfully able to build a test moduleset, and even some real modules such as zlib and iconv on windows using the mingw compiler. Things are looking promising and I will continue to play with this tomorrow. Its a bit of a pain to debug because of the inconsistancies between how subprocess.Popen behaves on windows and on linux. So far my changes can be summarised as follows
-
Add Makefile.win32 and patch install-check to just call /usr/bin/install
-
Replace wget/curl with pythons built in urllib.urlretrieve
-
Replace tar/unzip with pythons built in tarfile and zipfile modules
-
Misc fixes to get Jhbuild to start including disabling the tray icon etc
-
Refactor buildscript.execute (the subprocess.Popen) wrapper to clean it up and to special case local script commands from system commands (because of differences in how win32 treats executing executables in the current dir). Best summarised as the following
def execute_script(self, command, args_str='', cwd=None, extra_env=None):
# THIS IS THE MAIN WIN32 HACK
if sys.platform.startswith('win') and command[0].startswith('./'):
command = ['sh', command[0].replace('./','')] + command[1:]
Jhbuild still works on Linux just as it used to (more or less, I need to port over some more things to the new buildscript.execute() functions). Wget/tar/curl/unzip etc are still used on Linux. In general the changes so far have been self contained and should not break regular operation
The Install Procedure
How can you try this pre-alpha code out?. Follow these steps on windows and check out from my bzr branch (or use the patch against SVN)
-
Install MinGW combined installer (MinGW-5.1.3) to C:\mingw
-
Install msysCORE-1.0.11-2007.01.11 to C:\msys
-
Run C:\msys\postinstall\pi.bat, answer yes when it asks whether mingw is already installed and point it to C:/mingw. Launching C:\msys\msys.bat now provides us with a minimal unix-like shell.
-
Install Python 2.5.1 to default location (C:\Python25)
-
Install bzr for windows to the (C:\Bazaar)
-
Start msys.bat (in C:\msys)
-
Install Jhbuild
-
bzr co http://www.gnome.org/~jstowers/bzr/jhbuild-win32 jhbuild-win32
-
cd jhbuild-win32
-
make -f Makefile.win32 install
-
Add python to path. Other path manipulation is done within JHBuild. Add the following line to ~/.profile
export PATH=$PATH:/c/Python25:/c/Python25/bin
You should now have a minimal msys install with JHBUILD. Test by performing
-
cd ~/bin
-
python jhbuild --help
Finally, you can now install the test modules with
python jhbuild -f jhbuild-win32/test.jhbuildrc build test
Standard disclaimers apply, alpha quality code, help appreciated, yada yada yada. Now back to Conduit hacking....
