Sep 24, 2013
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
The difference is stark; compare the old and the new versions below;
In addition to the use of new widgets (
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.
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
- Better tweak names and descriptions (manage our own translations
instead of getting all from gsettings)
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,
and here again, and
wiki.gnome.org. Hope you all enjoy the
Feb 3, 2013
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
- sample consensus model fittting (RANSAC + others, cylinders, planes, common geometry)
The code tries to follow the Point Cloud API, and also provides helper function
for interacting with numpy.
A minimal example (demonstrating the
p = pcl.PointCloud()
fil = p.make_statistical_outlier_filter()
The main limitation of the current implementation is that is only supports
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
bindings I could find.
The current release has been tested with
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,
Jan 27, 2013
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 Gtk 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+GObject 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'.
- 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
- 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.
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 widgets. Advice on how to distinguish this use-case would be
def __init__(self, *args, **kwargs):
Gtk.Switch.__init__(self, *args, **kwargs)
self._changing = False
def _changed(self, *args):
def set_active(self, is_active):
self._changing = True
self._changing = False
def connect(self, *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
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.
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
performance 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.
Oct 19, 2011
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.
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!
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 cup, earthquake, rena oil spill).
This post has been brought to you by procrastination.
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.
May 31, 2008
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,
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.
Documentation availablitly. Follows from #1, can I actually learn and use the tool within the SOC duration.
The wrapping tool is actively developed.
Does not introduce additional runtime dependencies other than the library being wrapped.
Minimal compile time dependencies when creating the bindings.
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)
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.
The same as Pyrex, but some new nice features added
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.
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.
Writes C++. Not evaluated due to the additional dependencies required.
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.
It generates Boost.Python wrappers. Not evaluated.
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
This works like boost.python, but for the D language. Not evaluated.
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.
Insufficient documentation to evaluate.Similar approact to swig, sans the intermediate IDL.
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 (codegen.py and h2defs.py)
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, repo.or.cz, freedesktop git, launchpad.net bzr, mailing lists, twitter, $COMPANY gitweb, $PERSONAL gitweb, $DISTRO viewvc and gnome.org/$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 planet.gnome.org/svn-commits, 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;
planet.ubuntu.com seems to have excellent visibility of active development, even if it doesn't have as many developers as other distributions.
freedesktop (via planet.freedesktop.org and http://gitweb.freedesktop.org/) 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
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!
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 configure.ac - 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
Relaxing on the Jetty
Sunset at the Bay Of Many Coves
Oct 31, 2007
Conduit recently reached 1000 commits, and with it came together some functionality that has been brewing for a while.
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 . 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 gnome.conf.au. As an aside, I would be interested in talking to any of the RH online desktop folks at linux.conf.au as I am unable to make it to any of the northern hemisphere conferences on account of me being poor and in New Zealand.
 Excluding a dependence on gnomevfs (yuck). Hopefully gio/gvfs will make all my dreams come true.
Sep 25, 2007
There are a number of lively discussions currently going on in desktop-devel with regard to new module proposals . 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?
A HAL pretty formatting utility, so I may finally easily format my USB keys. Description here, and here
GSmartMix + PulseAudio + LibSydney
A dream bunch of projects providing policy for sound devices. GMartMix lives between gstreamer and pulseaudio (i hope...) to allow applications to mute, pause, and have per application volume control, although the latter may be the domain of Pulseaudio. LibSydney said to replace esd in GNOME (finally, down with cruft).
Mathusalem: Long running task manager
This SOC2006 project built sufficient buzz that KDE has now acquired an equivalent in KDE4. With Nautilus currently being broken to integrate the great new gvfs work, perhaps this would be a good time to play
New gnome-panel bling
Ohhh shiny. Im happy to see this come up on ddl, users like shiny things. Some more gnome-panel ideas here.
Libslab, Tiles and the New UI Metaphor, including Gnome Main Menu.
Gnome-control-center single window mode.
I know it met with resistance when it was introduced but I quite liked it!
GtkApplication and GtkUnique
Perhaps GtkApplication is a smart place to put the window DND stuff (now that nautilus supports XDS)
New GNOME Session Code
TOPAZ type infrastructure which may allow saving tasks to a file, or even a project or task oriented desktop.
Kwin is shipping with a compositor, as is the xfce window manager. It would be a shame to have nothing comparable (yes I am aware of Compiz, and sometimes it hurts to use)
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?
 I am also hoping that tracker and/or xesam gets proposed this cycle.
Sep 3, 2007
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
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!