Johns Blog

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;

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.

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)

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 wiki.gnome.org. Hope you all enjoy the release.

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()
p.from_file("C/table_scene_lms400.pcd")

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

fil.filter().to_file("inliers.pcd")

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.

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 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'³.

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.

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 widgets⁴. 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:
            self.stop_emission("notify::active")

    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 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.

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.

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).

Technology Tidbits

• gnome-tweak-tool is coming along nicely. I have some things in bugzilla to address, but I am happy with the state and direction.

• GNOME 3 has helped my productivity greatly, maximized windows, keyboard navigation and less distractions have been welcome changes.

• Pygtk is in maintenance mode (I need it to keep working for some of my UAV code). python-gobject and gobject-introspection are awesome and easy ways to write new GNOME apps.

• LaTeX is awesome, and I am happy we have returned the gedit-latex plugin to being the best way to write LaTeX on Linux.

• Nothing of value is ever said in comments on the internet.

This post has been brought to you by procrastination.

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

• Windows installer (homepage) (download)

• Mac improvements (all in one installer work) (bundling advice)

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.

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 (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.

Conclusions

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.

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 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.

Holidays

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

Hunter Gatherer

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 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.

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

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?

• Gnome Formatter 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.

• Metacity Compositor 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?

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

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)

• Support Amazon S3

• Support thunderbird contacts (mork library here)

• Support Liferea 1.4 feeds (they now are stored in a sqlite database - easy to parse)

• Delicious support

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!