Sep 24, 2013

GNOME Tweak Tool 3.10 Improvements

In collaboration with GSOC student Alex Muñoz and designer Allan Day, GNOME Tweak Tool has seen many improvements this cycle, both 'under the hood', and most noticeably, in the form of a modern GNOME3 UI design. The difference is stark; compare the old and the new versions below;

New UI

Old UI

In addition to the use of new widgets (Gtk.HeaderBar, Gtk.Application, Gtk.Stack, Gtk.SearchBar) the organisation of tweaks into categories has been updated. This should make many settings easier to find, especially in conjunction with new translations for many tweak names and descriptions.

Historically, the tweak tool UI was mostly auto-generated, resulting in a rather uniform and boring look, and more importantly the inability to easily group tweaks together to show causality (such as turning off desktop icons makes the options to show specific types of icons on the desktop redundant). This architectural limitation has now been fixed, and in addition, specialized UI elements have been created for certain tweaks; startup applications, shell extensions, desktop icons, the shell top bar, etc.

Desktop Icon Options

Other highlights of 3.10 include;

  • Allow updating GNOME Shell extensions from inside tweak tool
  • Startup application management
  • Offer to logout user when tweaks require the session restarted
  • GNOME style sidebar and search
  • Ability to disable middle-click paste (great for designers!)
  • Show text in tooltip when label is ellipsized, and make window maximizable and resizable.
  • Better tweak names and descriptions (manage our own translations instead of getting all from gsettings)

Startup Applications

Unfortunately, not all features I wanted to implement were completed. Things I will be working on in 3.12 include;

  • Hidpi tweak (this will land in 3.10.1)
  • Better search interaction (focus stealing and search-results layout fixes)
  • Improved layout when the window is maximized
  • Resurrect the wacom panel (this was generously contributed at the start of the cycle, but I had no time to port it to the new design, nor any way to test it)
  • Privileged helper for operations requiring root permissions (power management options, installing system wide themes)
  • Keyboard layout specialized UI
  • Theme management UI

For more information on GNOME 3.10 and GNOME Tweak Tool 3.10 check out world of gnome here, here, and here again, and Hope you all enjoy the release.

Feb 3, 2013

Python Bindings to the Pointcloud Library

I'd like to announce the release of python-pcl, python bindings to the pointcloud library.

This is not a full binding to the rather large PCL API. Currently, the following parts of the API are wrapped

  • I/O and integration; saving and loading PCD files
  • segmentation
  • sample consensus model fittting (RANSAC + others, cylinders, planes, common geometry)
  • smoothing
  • filtering

The code tries to follow the Point Cloud API, and also provides helper function for interacting with numpy.

A minimal example (demonstrating the StatisticalOutlierFilter

import pcl

p = pcl.PointCloud()

fil = p.make_statistical_outlier_filter()
fil.set_mean_k (50)
fil.set_std_dev_mul_thresh (1.0)


Filtering Example

The main limitation of the current implementation is that is only supports the PointXYZ point type. PCL is a heavily optimized and templated API, and the best method for creating specializations correspoinding to the correct point type in a dynamic language like Python is not clear.

Nevertheless, the binding is already capable of smoothing, filtering and the fitting of geometries in arbitary 3D point cloud data.

The binding is written using Cython, and is one of the more complex C++ bindings I could find.

The current release has been tested with

  • pcl 1.5.1
  • Cython 0.16

although it should work with more recent releases.

I would be interested in adressing the specialization issues using the recently added and improved fused types support in Cython.

This work has been supported by, and is currently in production use at, Strawlab.

Jan 27, 2013

ROS and Gtk for Laboratory Control

At the lab in which I work (Andrew Straw, strawlab) we study the visual flight behaviour of Drosophila using virtual reality. The implementation of this will be explained in future posts and papers however for this post I am going to describe how I used Gtk1 and ROS to build an interface to control and monitor running experiments (called the 'Operator Console').

A future post will address and release all the ROS+GObject2 glue that lets these interfaces scale dynamically as nodes (dis)appear. This just shows the relevant Gtk parts and has some comments on what I would like from Gtk to make these sort of interfaces easier.

The screenshow shows the first tab of the 'Operator Console'3.

Operator Console

Implementation Notes

  • I use the secondary icon support of Gtk.Entry to show the contents contain sensible data. Maybe validation support in Gtk would be useful here bug.
  • The 'Description' entry is a Gtk.TextView, not a Gtk.Entry. It was necessary to apply custom CSS to make it look reasonably similar. Sadly, it does not support the full/same set of CSS properties as Gtk.Entry, so it was impossible to show the same border radius and focus colors bug. Perhaps a multi-line Gtk.Entry would be better.
  • The bottom half of the window shows the utilisation of all computers. I tried a few versions of this, and simple sensibly formatted monospaced text looked much better than anything else I tried. Any suggestions?

This screenshot shows an example screen where we mix the control and monitoring or many instances of the same ROS node.

Operator Console

Implementation Notes

  • The Gtk.Switch simultainously displays the status of the projector, and also allows control of the node. The is a common use-case in the software, and due to the asynchronous nature of the ROS messages, I need to distinguish these from user-generated signals. I have wrappers such as the following for many widgets4. Advice on how to distinguish this use-case would be preferred.
class UpdateableGtkSwitch(Gtk.Switch):
    def __init__(self, *args, **kwargs):
        Gtk.Switch.__init__(self, *args, **kwargs)
        self._changing = False
        self.connect_after("notify::active", self._changed)

    def _changed(self, *args):
        if self._changing:

    def set_active(self, is_active):
        self._changing = True
        Gtk.Switch.set_active(self, is_active)
        self._changing = False

    def connect(self, *args, **kwargs):
        self.connect_after(*args, **kwargs)
  • The "Standby (Computer1)" is for display only and mirrors the status of a ROS topic. I would like some way visually to inicate that this widget is not actually an editable Gtk.Entry. Currently the Gtk.Entry is set editable = False, it looks to out of place with sensitive = False. Perhaps I should add some custom CSS to color it slightly different. Suggestions are appreciated.

Closing Remarks

I'm really happy with the status of the PyGObject bindings. We have a few quite large applications built using them (and ROS) and I have no complaints about performance5 or otherwise. The conventional wisdom was that PyGTK (and GTK) were not suitable for threaded workloads but the threading model of ROS guarentees that the 'operator-console' shown above manages upwards of 50 background threads asynchronously updating the GUI state.

  1. Actually PyGObject, argh why didn't we keep the name as pygtk? 

  2. I'll blog about this later. For the curious, rosgobject lives here. 

  3. In real operation this GUI shows the state of many more machines/nodes/computers. This screenshot is running on my laptop because showing too much more might give away the game ;-). 

  4. freeze_notify and thaw_notify would almost work, if the events could be dropped and not queued. Also, not all widgets use notify::active, GtkComboBox(Text) for example. A general way to do this would be preferred. 

  5. Excluding plotting / graphing performace. But that is fodder for a later post. 

Oct 19, 2011

A Change

2011 has been an interesting year. Between the stupid earthquakes and the pressure of finishing my PhD, I have been silent because I have had nothing interesting to talk about (cf. twitter...).

But there is a light at the end, I'm on track to complete my thesis, 'Biologically Inspired Visual Control of Flying Robots', in December/January.

Christchurch, demolished, the old...

I'm excited to say that I have accepted a job at the Institute of Molecular pathology, in a research group studying the mechanisms of visual flight control in insects. Technology wise, it is a perfect fit; the experimental apparatus involves a multi-camera real-time flight tracking system and estimator for multiple targets in an augmented reality flight arena. It is open-source (ish), and python/numpy. Research wise, it allows me to investigate some of the assumptions and unknowns in the biomimetic control systems I implemented during my PhD. And it is in Vienna, 1st Feb, 2012!

Vienna, the new...

This is a career change for me. In the last few years it became increasingly clear that I was morally uncomfortable with the use of UAVs as weapons (drones). Previously I had consoled myself with there existing an ethical and philosophical difference between 'the application of research' and 'the action of research'. When It came to looking for work, and considering who to work for, this difference was often eroded.

It has also been particularly frustrating being in New Zealand for the last 12 months and watching our flaccid national response to the three recent challenges here (world cupearthquakerena oil spill).

Technology Tidbits

This post has been brought to you by procrastination.

Apr 3, 2011

End of an Era: PyGTK

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.

May 31, 2008

SOC Report: Week 1

Well the first week of summer of code has finished. This week I spend my time evaluating and testing the various options available to (semi)automatically wrap C code (libsyncml) so that it is accessible from Python. My priorities when evaluating the options go something like,

  1. Capability - the tool should be able to (semi) automatically wrap a large majority of the libsyncml api. Any customizations required in order to make the wrapping more complete should be readable and maintainable by people other than myself.

  2. Documentation availablitly. Follows from #1, can I actually learn and use the tool within the SOC duration.

  3. The wrapping tool is actively developed.

  4. Does not introduce additional runtime dependencies other than the library being wrapped.

  5. Minimal compile time dependencies when creating the bindings.

  6. Community service value (i.e does the selection and use of the tool bring a positive benefit to the FOSS ecosystem greater than the actual library being wrapped).

The following is a list of available options I looked at (see cython for more explanation)

  • Pyrex Produce very nice and clean C file, which you just compile to .so and that's it. Allows to wrap almost any C and C++ code. IDL is python-ish.

  • Cython The same as Pyrex, but some new nice features added

  • SWIG The defacto standard I guess. SWIG is one of the oldest and most mature methods of wrapping C or C++ code into Python (SWIG works for other target languages as well). SWIG produces a C file from an IDL, which gets compiled to a .so, but then it also produces a Python wrapper on top of this. Because Python wrappers are written for you, if their design is not exactly what you want, you end up doing more work to create your final Python API.

  • SIP Similar to SWIG, but only aimed at wrapping C and C++ to Python. Unlike SWIG there is no Python wrapper. Used by PyQT and PyKDE.

  • Boost.Python Writes C++. Not evaluated due to the additional dependencies required.

  • Ctypes Ctypes is included standard in Python 2.5. The IDL is typically a python class hiding the ctypes calls, making the API more pythonic. It allows one to call library functions defined in shared object libraries directory from interpreted Python code.

  • Py++ It generates Boost.Python wrappers. Not evaluated.

  • f2py It's mostly for wrapping fortran files, but it can also wrap C files, even though it's not a very well-known feature. Not evaluated

  • PyD This works like boost.python, but for the D language. Not evaluated.

  • Interrogate This works similar to SWIG. It created dynamic link libraries that can be used both from python and c++ via the Python C API. No other files are needed. Its not very well documented but is used in several commercial mmorpg's and is native to the Panda3d engine. Not evaluated.

  • Robin Insufficient documentation to evaluate.Similar approact to swig, sans the intermediate IDL.

  • PyBindgen The IDL is itself python, and it generates clean readable dependency free C code. Designed for wrapping C++, but has some support for wrapping C libs.

  • pygobject ( and The Gobject way, and the way I am most familiar. Unfortunately, in order to wrap the libsyncml library I would first need to wrape it in GObject.


The libsyncml library uses the Gobject mainloop, and custom error types. In order to integrate this with pygtk applications It would need to link to Pygobject/C, and propogate the error types to exceptions.

Somewhat unsurprisingly, the weak point in almost all of these approaches is there documentation. While I like the look of PyBindgen, it is a nightmare to build, and docs are sparse. The SWIG IDL is hairy, and one must also maintain pythonic wrappers to make a nice library. Pyrex and friends do not seem suited to the integration of libsyncml and pygobject without additional C glue

At this stage I am leaning towards SWIG, for community service value (others can come along after and make C# wrappers for instance), its availability of documentation, and even if the IDL is quirky, others are familiar with it.

Distributed Version Control Systems and visibility of development

My opinion on the 'best' DVCS is not relevant. What I am concerned about is that if GNOME does not pick one, and/or provide some sort of hosting or method to track other peoples development branches then the visible activity level, and subsequently health of the whole project will suffer.

The premise here is that centralized version control systems make it easy to follow what developers are working one, and the activity level of development, via the svn-commits mailing list for example.

I can only offer anecdotal evidence here, but I think that the visibility a projects development is just as important as the actual rate of development being done.

  • If developers cannot see what other people are hacking on, then there is the potential for duplication of work, or conflicting implementations.

  • If users do not see people actually doing work, then there is a tendency to assume the project is 'abandoned' or dead. The only thing worst than a 'dead' project is being proclaimed as such when one is not.

I consider the plethora of ways one can follow what developers are doing part of the problem, not part of the solution.

Who has time to follow planet, IRC, github,, freedesktop git, bzr, mailing lists, twitter, $COMPANY gitweb, $PERSONAL gitweb, $DISTRO viewvc and$USER_HOME_DIR  to see what people are working on.

This post is not meant to be Reductio ad absurdum, its just a slight generalization of why I read, etc, etc.

  • Part of the reason is to see what other hackers are up to.

  • Part is academic, to learn techniques and design from some of the great hackers on here.

  • Part is flagrant procrastination.

  • The small remaining part is the keep the voice in my head thats says "you should be using KDE, it appears to be more actively developed" at bay.

Conclusions, if any;

  • seems to have excellent visibility of active development, even if it doesn't have as many developers as other distributions.

  • freedesktop (via and seems to have excellent visibility of development (many people put git branches in their home directories, which are subsequently picked up by gitweb).

  • I am not advocating activity over productivity (obviously we are all free to use the tools which allow us to be the most productive, not just appear the most active). I just think that public FOSS development is an interesting space, in many ways the developers of the products are the marketers of it.

  • GNOME used to have the balance of visibility about right, but I think we are losing that with all this dilution.

Change scares me. That is all.

Jan 16, 2008

Back To Reality

Conduit 0.3.5: Enough Excuses

I am a terrible project maintainer. It has been a full 3 months since the last Conduit release, and I have run out of excuses. First I got distracted by online desktop shenanigans, then by Opensync and Ubuntu things. I got caught up in moving Conduit to GNOME SVN. Then I got distracted by JHBuild on windows. Finally I lost my nerve and went on holiday, not touching a computer for 3 weeks. Enough is enough!

The good news however is that there is no doubt in my mind that this is the best Conduit release ever. I'm using Conduit on a daily basis for a variety of tasks, and its looking really solid. Yes there are still some bugs, but thats life. So, no screenshots this time, just a list of shiny new features. Over the next few weeks I will be doing a series of "look what you can do with conduit" type posts, as this is probably the best way to demonstrate to folks what they can accomplish with a generic sync+conversion framework, with a focus on integration with the desktop environment and great support of online services!

  • Release Notes

  • Download

  • Report Bugs

  • Whats New

    • Move to GNOME SVN and Bugzilla

    • In memory mapping DB has been replace with sqlite based one. Should reduce memory usage during large sync's.

    • Restructure code layout to allow Conduit to be used as a library by other python programs.

    • Removed Gtk dependancy in core. Conduit command line can now be run without Gtk installed.

    • Added 'always up to date' infrastructure for automatic syncing.

    • Improved n800 support for syncing audio, video and photos to the device.

    • New AudioVideoConverter for transcoding media types (uses FFMPEG and/or mencoder)

    • Include Banshee support in - from lool

    • Support data hashes in addition to mtimes as a means for detecting changes

    • Remove twisted dependency for network sync. Uses the built in python xmlrpc module

    • Use python logging module for better logging granularity

    • Make HAL easier to extend in dataprovider factories

    • Files that did not load correctly are shown in the preferences window to help debugging

    • Experimental maemo/hildon UI (Thomas)

    • Added iPod photos support

    • Write support in f-spot using its new dbus interface (Thomas)

    • Support tags in all datatypes (useful for images)

    • Incredible improvements in test coverage. 75% lines of core code tested (including close to 100% of the core sync engine)

    • RSS Feed source now supports video enclosures

    • Many many bug fixes as a result of test focus

As more people start to use conduit I am becoming more conservative and focusing a lot more on testing. One aspect of this is a machine I have set up that runs the test suite every time there is a commit. The other aspect is more regular releases. For the former look here, for the latter please test and give me feedback!

Team conduit is well poised for a 0.4.0 release to coincide with GNOME 2.22.


It feels strange to be back at university after a solid 3 weeks of doing very little. I had the best summer holiday I have had in a long time. Considerable thanks must go to the weather in New Zealand, its great to finally have the good weather in December. Anyway here are some holiday snaps for those that are curious about what a summer Christmas/New Year in New Zealand looks like.

My Christmas Present My Christmas Present

Relaxing on the Jetty Relaxing on the Jetty

Sunset Sunset at the Bay Of Many Coves

Diving Hunter Gatherer

Oct 31, 2007

One Thousand

Conduit recently reached 1000 commits, and with it came together some functionality that has been brewing for a while.

  • Far far far improved nokia n800 support

    • You can now sync files, photos, music, and videos to your nokia n800 in an intelligent way (i.e. its not just a dumb file/folder sync).

    • The ability to transcode said data to the most appropriate format for the device. FFmpeg/Mencoder is used to transcode audio/video, and gtk.Pixbuf is used to convert photos. The converters use conduits built in dynamic modular plugin system, so if someone wants to write a audio video converter using GStreamer then please contact me.

    • Also, those that are familiar with FFmpeg/Mencoder/Transcoding please feel free to contribute preset encoding profiles (video codec, size, etc). Presets are stored here (video), here (audio) and here (photo).

Another one of those conduit screenshots that always look the same

  • Looser dependence on gtk. This means that conduit can be run from a console (-c command line switch) without gtk/goocanvas installed. This reduces the memory usage by about 10Mb!

  • Massive refactoring effort to aid more code sharing between dataproviders and the complete decoupling of the GUI from the core application. This allows other guis to written very independently of the rest of the application [1]. Stay tuned for a native hildon gui for nokian800 and/or ubuntu mobile.

  • Rhythmbox support. A simple dataprovider has been added that is able to sync rhythmbox static playlists with things. Initially this is used to test sync music with n800 (with the ability to transcode audio formats), but in my ideal world, sync with rhythmbox would involve

    • Improving rhythmboxes DBus interface to support adding/removing songs to the library and querying playlists (including smart playlists).
  • Remember because we are gnomevfs aware some cool things are possible. For instance, one can sync + transcode videos/music to/from their phone which is mounted using gnomevfs-obex.

  • Work is currently proceeding furiously on

    • Integrating with opensync

    • Removing the twisted dependence, and using pythons built in xml-rpc server for network synchronization

    • Replacing our current in memory database with one based on sqlite

    • Support for iPod photos

    • Test coverage andbug fixing.

Anyway, svn HEAD is pretty rocky at the moment, but please experiment. Once the database changeover has taken place things should stabilise for a 0.3.5 release. This will be a release candidate and then we will focus on bug fixing only.

Ideally we will release a stable 0.4.0 release at or before As an aside, I would be interested in talking to any of the RH online desktop folks at as I am unable to make it to any of the northern hemisphere conferences on account of me being poor and in New Zealand.

[1] Excluding a dependence on gnomevfs (yuck). Hopefully gio/gvfs will make all my dreams come true.

Sep 25, 2007

What Ever Happened To?

There are a number of lively discussions currently going on in desktop-devel with regard to new module proposals [1]. This reminded me of a few projects I used to follow that I have not heard from in a while. Hoping not to offend any of the developers I therefore ask,

What ever happened to?

Anyway, its great to see the action on ddl, and the excitement surrounding GNOME again. I look forward to the next release. I will be releasing a Conduit 0.3.9 (the RC before 0.4.0) this weekend, and here is a hint about my next blog post: Conduit as a blessed GNOME dependancy, how can we integrate Sync into the desktop?

[1] I am also hoping that tracker and/or xesam gets proposed this cycle.

Sep 3, 2007

Expanding the Sync Space

No screenshots this time, but still good news. Conduit tries to be a good citizen, integrating itself with GNOME technologies. Recently the following hacking has been going on (not all items are complete)

  • A Eye Of Gnome plugin allowing photo upload/sync to Flickr, Picasa, SmugMug, Facebook (soon)

  • Gnome user documentation

  • Themable icons

  • Patches to improve FSpots DBus interface to allow two way syncs with photo sites

  • Continued work on OpenSync integration. We have limited support for arbitary opensync plugins!

  • Canola, n800, Rhythmbox and general music synchronization

There have also been some new contributions

  • Two way support for Flickr, Picasa and Smugmug. Now you can move your photos between sites (AKA move my data)

  • A youtube dataprovider (sync your fave videos each morning)

  • Google calendar support (sync evolution with google calendar, iPod, etc)

Anyway if you are looking to get involved with Conduit now is a great time. I have just updated the docs on how to write a dataprovider. Here are some ideas for dataproviders people may wish to write (hint hint)

There will be some new features landing in trunk soon that will allow arbitrary parameters during the conversion process, i.e. transcoding audio/video to another format, resizing photos, compressing files, etc. Watch this space, download conduit, and go tell people it rocks!

Next → Page 1 of 3