Apr 3, 2011
I just released PyGTK 2.24, which will almost certainly be the last major PyGTK release. The future of Python on the GNOME platform is PyGObject + GObject Introspection. From my experience over the last few months porting a number of my projects, the future is bright.
In a cruel twist of irony, the state of PyGTK on Windows and Mac has never been better. The credit for the windows work (and some great documentation improvements this cycle) must go to Dieter Verfaillie
I hope that the new stack will reach the same level of capability on other platforms as GTK+ 2.24, but in the large scheme of things the renewed development excitement surrounding GTK+ 3.0 and GNOME 3 is excellent consolation.
As a user I would like to thank those developers before me for creating PyGTK. It was the first 'pythonic' UI toolkit for linux, and a pleasure to use. As the recent maintainer of PyGTK I would especially like to thank those recent developers who helped me, in particular Dieter Verfaillie who really pushed PyGTK over the line regarding Windows support, into the great state it is now.
I'll leave you with some graphical statistics (generated using pepper) for the 12 year history of PyGTK. If planet strips the wordpress gallery then please click here.
update: To clarify a point raised in the comments, PyGTK will be maintained in the exact same was as the GTK+-2.0 series will be maintained. Bug fix releases will be made if necessary, but no new features will be added. If you want the new GTK+-3.0 features then you should use PyGObject + GObject Introspection.
The PyGTK code will not disappear from any servers, it will continue to be shipped in all distributions for the forseeable future, it will continue to work very well on windows, and many applications will continue to use it.
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.
Jan 22, 2010
I had two days off while I moved offices, so I got a chance to catch up on my backlog of random hacking.
osm-gps-map
I released osm-gps-map v0.5.0 which adds a few new features (such as keyboard navigation) but also contains many bugfixes and performance improvements. Check the release notes for more information. The next item on the TODO is merging the OSD/layers branch.
Conduit
I released Conduit 0.3.17 which was long overdue. Mostly a bugfix release and updating to new API. The Conduit homepage has also moved to live.gnome.org. Progress on Conduit is a bit slow at the moment, it does everything I want it to (I have a budget cellphone so phone synce does not interest me), and is pretty stable. I have some SOC work I would like to merge, but basically I am looking for developers and inspiration...
PyGTK for Windows
I finished off the fixes to build correct PyGTK+ installers on windows, hopefully closing bug #589671. I uploaded new installers with the fixes people have reported. I expect these installers to become the 'final' installers at some point. Feedback welcome.
PyGTK Hacking
I wanted to play with the new client side windows work in Gtk+, so I ported the effects gtk-demo to Python. This required a bit of ctypes magic to access the new API (good), and some more ctypes magic to interact with new signals that appears to have unfriendly prototypes (not so good, bug filed here).
Jan 11, 2010
It has been a long time between blogs. I thought I should talk about the piece of software that has been responsible for the most emails in my inbox over the last few days - osm-gps-map, the Gtk+ based map widget. What started as a widget for use in one small application of mine has grown considerably.
-
I recently released 0.4.0, a bugfix release.
-
I created a mailing list, if you are a user or interested osm-gps-map, them please join.
But I thought I should take some time to highlight some of the most interesting users of osm-gps-map, particualry those users on the Maemo platform.
Maep, OSM2Go and GPXView (by Till Harbaum)
BrainStorm (by Adam Boggs)
- BrainStorm is a storm chasing application that plots your track, and overlays current radar and severe warning imagery on the map.
eCoach
- eCoach is an application for recording and managing sport activities with Nokia N900, it records heart rate data from various monitors, and plots your path on the map as you exercise.
Conclusion
-
With the help of these users, the future of osm-gps-map looks very positive.
-
I am currently working on merging Till's improvements to master to discourage people from copying osm-gps-map source into their application.
-
If you are a user of osm-gps-map and I have forgotten you then I am sorry. Please contact me and join the osm-gps-map mailing list.
Jan 22, 2009
It has been a long time between posts, but I am back in New Zealand now, and vowing to get back on top of this blogging thing. I will post more in the coming weeks about my time in France with the ENAC crew, but I will start today small; by releasing some code I have been hacking on.
I wanted a small project to get back into the desktop development mindset after being in the embedded C (ARM 7 LPC2148) and OpenEmbedded (Beagleboard and Gumsix Overo) world for a while. I am also ecstatic that git was clearly the most popular DVCS in the recent survey, I really hope it provides the impetus for GNOME to move to a DVCS.
With that in mind I decided to use this small project to learn git. Firstly, github.com is the coolest thing I have ever seen. I am moving all of my projects (except Conduit) there, and using the pages and wiki features to document them as appropriate.
Facebook Notify
Facebook Notify is a small PyGtk application which monitors your Facebook profile and notifies you when it changes. Some would consider it a gross abuse of the GNOME notification area, but it keeps me out of the web browser, decreasing procrastination, thereby improving my productivity.
It notifies you when any of the following events occur;
-
One of your friends changes their status, profile picture, or profile details
-
You receive a friend request, event or group invitation
-
Someone writes on one of your friends walls
-
One of your friends is tagged in a photo
The code is a few days work, and nothing impressive. It does however contain a rather nifty deferred threaded network io system so to never block the GUI. I guess something similar could be done in C + libsoup + GTask, if one was allowed to arbitarily chain callback functions. I remeber seeing a bug and discussion about this somewhere.
The main bug is that WebKitGtk segfaults if you destroy the WebView after logging into Facebook. Not cool. Anyone know anything about this bug? Is anyone going to make an updated libwebkitgtk release soon?
So, please, fork my code. That way I have a real life example to practice merging from!
Mar 12, 2007
At the request of a few people I have made a demo to share, showing how I do threading in a pygtk application (Conduit). I find the following approach seems to work reliably and requires little code. Other approaches can be found here and here.
This approach takes advantage of the fact that signal emission in glib has been threadsafe since glib 2.8 (IIRC). All communication with the GUI is done via gobject signals. There is definitely a compromise in the level of GUI fiddling that you can do, particularly when compared with the threads_enter/leave approach. However, I have found this signal based approach sufficent in my case, and that it encourages me to decouple the slow blocking tasks from the GUI.
A lot of the tasks in conduit take a long time (network limited), and there is no real need for extensive GUI interaction with them once they have been started. I am really only interested in their progress, and when they complete. With this in mind I have implemented the following approach;
-
FooThreadManager
This class is the entry point for starting threads (the make_thread() method) . Its basically just a threadpool that starts threads with the appropriate arguments, while restricting the number of concurrent running threads below a user defined limit. It also connects the threads to the supplied user callbacks.
-
_IdleObject
Like a normal gobject.GObject but emits all signals in the main thread
-
__FooThread_
A simple class which derives from both threading.Thread and _IdleObject. All work is done in run() and a signals are emitted when the thread completes and to show progress
-
Demo
A simple demo (see screenshot) which can start a whole bunch of threads and receive notification when they complete.
Anyway, the Example Code is a bit contrived and will certainly need some customization by the user but nonetheless may still be useful to others.
Update: Thanks to comments I fixed up a thread-safety issue. I had misunderstood that signal handlers get run immediately in emit(). Now the code emit()s on an idle_handler so all signals and callbacks are run in the main thread. As i mentioned, I use this approach in situations where the threads may run and block for a long time, so the burden of processing all the signals in the main thread is not a big deal as they do not occur frequently.
Update 2: Added progress reporting
