Like every year, I am driving to Berlin this week to attend LinuxTag 2012 to attend the excellent program. If you want to meet up and chat about projects, technologies, Free Software or other things, send me an email or leave a comment with this post and we will arrange for it.

I’ve always wanted to try to fly in a small airplane, and this weekend my girlfriend got me as birthday present a short introduction into ultra/microlight aircrafts, including a 30-min flight. I operated the aircraft during the whole trip, except for takeoff and engine-less landing, and I even got a video of it!

The flight started from the small town of Camarenilla, and we ended up flying over the beautiful city of Toledo, one of the former capitals of the Spanish Empire.

This short video comes with the original audio:

This long video comes with music, and includes the recording of most of the trip, including landing.

Once upon a time, like 5 weeks ago, there used to be the longstanding plan to, at some point in the future, port GIMP to GEGL.

We have done a lot of refactoring in GIMP over the last ten years, but its innermost pixel manipulating core was still basically unchanged since GIMP 1.2 days. We didn’t bother to do anything about it, because the long term goal was to do all this stuff with GEGL, when GEGL was ready. Now GEGL has been ready for quite a while, and the GEGL porting got assigned a milestone. Was it 2.10, 3.0, 3.2, I don’t remember. We thought it would take us forever until it’s done, because nobody really had that kind of time.

About 5 weeks ago, I happened to pick up Øyvind Kolås, aka Pippin the Goatkeeper to stay at my place for about a week and do some hacking. After one day, without intending it, we started to do some small GEGL hacking in GIMP, just in order to verify an approach that seemed a good migration strategy for the future porting.

The Problem: All the GimpImage’s pixels are stored in legacy data structures called TileManagers, which are kept by high level objects called GimpDrawables. Each layer, channel, mask in GIMP is a GimpDrawable.

A typical way to do things is:

TileManager *tiles = gimp_drawable_get_tiles (drawable);
PixelRegion region;

pixel_region_init (&region, tiles, x, y, w, h, TRUE);

/* do legacy stuff on the pixel region in order to change pixels */

After the GEGL porting, things would look like that:

GeglBuffer *buffer = gimp_drawable_get_buffer (drawable);

/* do GEGL stuff on the buffer, like running it through a graph in order to change pixels */

Just, how would we get there? Replacing the drawable’s tile manager by a buffer, breaking all of GIMP at the same time while we move on porting things to buffers instead of tile managers? No way!

The Solution: A GeglBuffer’s tiles are stored in a GeglTileBackend, and it’s possible to write tile backends for arbitrary pixel storage, so why not write a tile backend that uses a legacy GIMP TileManager as storage.

After a few hours of hacking, Pippin had the GimpTileBackendTileManager working, and I went ahead replacing some legacy code with GEGL code, using the new backend. And it simply worked!

The next important step was to make GimpDrawable keep around a GeglBuffer on top of its TileManager all the time, and to add gimp_drawable_get_buffer(). And things just kept working, and getting easier and easier the more legacy code got replaced by GEGL code, the more GeglBuffers were being passed around instead of TileManagers and PixelRegions.

What was planned as a one week visit turned into 3 weeks of GEGL porting madness. At the time this article is written, about 90% of the GIMP application’s core are ported to GEGL, and the only thing really missing are GeglOperations for all layer modes.

As a totally unexpected extra bonus, there is now even a GEGL buffer tile backend in libgimp, for plug-ins to use, so also plug-ins can simply say gimp_drawable_get_buffer(drawable_ID), and use all of GEGL to do their stuff, instead of using the legacy pixel region API that also exists on the plug-in side.

GIMP 2.10’s core will be 100% ported to GEGL, and all of the legacy pixel fiddling API for plug-ins is going to be deprecated. Once the core is completely ported, it will be a minor effort to simply “switch on” high bit depths and whatever color models we’d like to see. Oh, and already now, instead of removing indexed mode (as originally planned), we accidentally promoted indexed images to first class citizens that can be painted on, and even color corrected, just like any other image. The code doing so doesn’t even notice because GEGL and Babl transparently handle the pixel conversion magic.

The port lives in the goat-invasion branch in GIT. That branch will become master once GIMP 2.8 is relased, so the first GIMP 2.9 developer release will already contain the port in progress.

If you want to discuss GIMP and GEGL things with us face to face, join us at this year’s Libre Graphics Meeting in Vienna, in two weeks from now, a lot of GIMP people will be there; or simply check out the goat-invasion branch and see the goats yourself.

If you have some Euros to spare, consider donating them to Libre Graphics Meeting, it’s one of the few occasions for GIMP developers, and the people hacking on other projects, to meet in person; and such meetings are always a great boost for development.

During the 3 crazy weeks, quite some work time hours were spent on the port, thanks to my employer Lanedo for sponsoring this via “Labs time”.

Location information in ModemManager

Since MM 0.5 at least, ModemManager comes with a Location interface which is defined to expose not only 3GPP-specific location information (operator MMC/MNC + Location area code + Cell ID), but also GPS-specific location information (cached NMEA traces and raw location information). In MM 0.7, this Location interface will actually work for GPS location, at least for Option modems with GPS capabilities.

The HSO plugin

The High-Speed Option plugin is probably one of the most complex plugins being handled in ModemManager. In the new ModemManager 0.7 codebase, HSO modems (MMBroadbandModemHso) are implemented as a subclass of the standard Option modems (MMBroadbandModemOption), as they share lots of common features (allowed modes management, access technology and signal quality reporting…); but they also implement lots of connection related HSO-specific features (e.g. success of a connection establishment gets notified via unsolicited messages), which are most of them handled in a new HSO-specific bearer. Some of these advanced Option modems come with additional surprises: GPS-specific ports (AT port for control, raw serial port for NMEA traces).

The HSO modems provide detailed information about the type of each port being exposed in the USB interface; and so during the probing phase we are able to easily grab the GPS-control AT port and the additional serial port for NMEA traces (handled by a new MMGpsSerialPort port type). Once the HSO modem knows it has these two ports, it will allow to enable or disable any of the two GPS-specific location sources (NMEA or raw), or both at the same time. The NMEA location source will enable the modem to expose the last cached NMEA traces; while the raw location source will tell the modem to just expose generic location information such as time, latitude, longitude and altitude. In the case of the HSO modem (and possibly in every other case), both location sources are actually implemented based on the same NMEA traces received (raw information is parsed from $GTGGA traces). In addition to the core GPS location handling and the HSO-specific implementation, libmm-glib and mmcli where also improved to easily play with the new features.

Trying the GPS location retrieval with your Option modem

If you want to give a quick try to these capabilities, grab ModemManager git master, compile, install and plug in your modem. You first need to check whether the modem has GPS-specific location capabilities. Note that we’ll assume the modem is exposed as index 0; if you have more than one modem, just use --list-modems to check the proper modem index:

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: 'none'
           |      signals: 'no'


The output says that the modem supports 3GPP Location area code/Cell ID, GPS raw and GPS-NMEA location sources. None is enabled yet, as we didn’t enable the modem, which we can do issuing:

$ sudo mmcli -m 0 --enable
successfully enabled the modem

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: '3gpp-lac-ci'
           |      signals: 'no'


The 3GPP location source will always be enabled by default if it is supported by the modem, while the GPS-specific ones will always be disabled by default. The reasoning behind this is that the 3GPP LAC/CI comes for free in C(G)REG notifications when C(G)REG=2 is supported, while the GPS location is usually an additional module in the modem, with high power consumption. Using mmcli, we can now enable both GPS raw and NMEA location sources:

$ sudo mmcli -m 0 \
             --location-enable-gps-raw \
             --location-enable-gps-nmea
successfully setup location gathering


If we do check again the status, we’ll see the GPS-specific locations are enabled:

$ mmcli -m 0 --location-status
/org/freedesktop/ModemManager1/Modem/0
  ----------------------------
  Location | capabilities: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      enabled: '3gpp-lac-ci, gps-raw, gps-nmea'
           |      signals: 'no'


Once they are enabled, ModemManager will start receiving NMEA traces in the GPS raw port, and will start to cache and process them. mmcli allows to show location-source-specific information with --location-get-3gpp, --location-get-gps-nmea and --location-get-gps-raw; but it also allows to query for all at the same time:

$ sudo mmcli -m 0 --location-get
/org/freedesktop/ModemManager1/Modem/0
  -------------------------
  3GPP location   | Mobile country code: '214'
                  | Mobile network code: '3'
                  |  Location area code: '21071'
                  |             Cell ID: '7033737'
  -------------------------
  GPS NMEA traces | $GPGGA,,,,,,0,,,,,,,,*66
                  | $GPRMC,,V,,,,,,,,,,N*53
                  | $GPGSA,A,1,,,,,,,,,,,,,,,*1E
                  | $GPGSV,4,1,16,24,,,,29,,,,05,,,,18,,,*7A
                  | $GPGSV,4,2,16,22,,,,14,,,,11,,,,17,,,*7B
                  | $GPGSV,4,3,16,03,,,,12,,,,30,,,,13,,,*78
                  | $GPGSV,4,4,16,23,,,,15,,,,27,,,,07,,,*79
                  | $GPVTG,,T,,M,,N,,K,N*2C
  -------------------------
  Raw GPS         | Not available


Note that ModemManager will expose only the last received NMEA traces of each kind, except for those ($GPGSV here) that are actually building a sequence.

Once the GPS module fixes a position, we’ll process the $GPGGA NMEA trace to get valid GPS location information:

$ sudo mmcli -m 0 --location-get-gps-raw
/org/freedesktop/ModemManager1/Modem/0
  -------------------------
  Raw GPS         |  UTC time: '155142.2'
                  | Longitude: '-3.513941'
                  |  Latitude: '40.502603'
                  |  Altitude: '18.000000'


What about other modems?

Well, if the modem exposes GPS-specific ports in the same USB interface, it shouldn’t be difficult to add support for them, specially now that all the core/libmm-glib/mmcli work is already available.

A special case is when the modem exposes a single AT port via USB and the GPS port via RS232 (e.g. Sierra Wireless FXT009 with GPS extension). This case is a bit more tricky as there is no easy way for ModemManager to tell that the RS232 port is to be managed by the same modem object created after grabbing the AT port. In this case, the user may need to explicitly set some magic udev tags to let ModemManager handle the needed logic, but that also may get tricky if the user has more than one such modem plugged in (not sure for what, but anyway).

The Planetary Virtual Observatory and Laboratory (PVOL) is an online database of amateur images of the outer planets (Jupiter, Saturn, Uranus and Neptune). It was developed in early September 2004, during my attendance to the first NVO Summer School in Aspen (Co, USA). It was first put online during November 2004, so we already celebrated its 7th birthday.

After a bit more than 7 years online, it was time to prepare some charts showing the evolution in the number of images published. The following graph shows the number of images of Jupiter available since year 2000 (PVOL inherited the images already available in the previous IOPW page).

And the 2011-2012 apparition of Jupiter didn’t even finish yet!

So, thanks to the growing community of amateur astronomers (260 listed today) publishing images in the PVOL, and special thanks to the Planetary Sciences Group of the UPV-EHU for the great work they’re doing managing the system.

Student applications for Google Summer of Code 2012 will be open very soon. After an extremely enjoyable and rewarding experience with the program last year, I feel it’s my duty to student programmers to get the word out. So, here’s why you should apply.

You get paid to work on open source software. I became a long time user, first time contributor early last year. Looking to give something back, I attempted a LibreOffice Easy Hack. In a case of fantastic timing, they announced their involvement in GSoC a week or so later and I got in touch. The end result was a whole new open source library. I had an amazing experience working with LibreOffice but it’s ideal to choose a project that’s personally useful. GSoC doesn’t require that you’re an open source evangelist but if you are, it’s a strong argument for applying.

It’s fantastic experience working on a large project. I feel I learned more during those three months than during my undergraduate degree course. I have to say that I never particularly enjoyed groupwork at university but it’s completely different if you’re working with smart, motivated individuals who’re there either because they want to be or because they’re paid to be (quite often both). As a nice bonus, it’s great work experience and has essentially led me to my dream job. I’m not sure if that’s a typical result, but it certainly wouldn’t hurt to have it on your CV or resume.

You meet some of the smartest, most awesome people (not all of them programmers). I think this is my favourite outcome. I’ve met people from all over the world with an assortment of beliefs, opinions and backgrounds. My experience was that some of the best hackers and coolest people (no, seriously!) hang around open source communities.

Applying isn’t difficult, just choose a participating open source organisation or two and do a little research into the suggested projects before getting in touch with them. Good luck!

Back in 2010 I started working on a CoreText backend for Pango (blog post 1, blog post 2). I got into trouble with implementing fontsets properly, so the code bitrot on my disk for a full year until I decided to commit a barebones version of the backend without fontset and font fallback support in April 2011 (blog post).

In the second half of 2011 Xamarin and Lanedo teamed up to improve GTK+ on Mac OS X in order to enhance the experience of the MonoDevelop IDE on OS X. Part of this work was to implement proper font fallbacks. This means that when characters are to be rendered which are not in the current font (for example Japanese characters which are not present in a Latin font when rendering mainly Latin text), we should fallback to another font containing these characters instead of drawing ugly boxes with hexadecimal numbers.

This allowed me to dust off the fontset patches I started working on back in 2010 and to investigate how to make fontsets work in the CoreText backend for real (nasty details are available in bug 647969, especially comment 3). We ended up with something that works nicely on both Snow Leopard and Lion. The reliance on a CoreText symbol that’s not in the header files (not nice, I know) has not shown to be a problem so far.

In conjunction with this, we also improved the shaping engine of Pango’s CoreText backend. The shaping engine can now better deal with the output from CoreText’s typesetter which we use to obtain the list of glyphs to render. Especially dealing with zero-width spaces, in both rendering and cursor handling, now works properly and was completely broken before. For some other corner cases (in particular with regard to some non-Latin scripts), we have ensured these are dealt with such that no crashes occur elsewhere in Pango. To fully support these cases, the shaping engine could use further improvement; see the source code comments.

All of this work is available in Pango’s master branch. It is great to see this upstream, together with the many other improvements we have made together with Xamarin so far!

If you have free time, and experience with gtk-doc documentation or man pages, ModemManager developers will thank you [1] if you help writing the new libmm-common, libmm-glib and mmcli documentation:
[MM 0.6] Documentation

If you have free time, basic GLib/GIO development knowledge, and a broadband modem (either USB dongle or internal) to play with, ModemManager developers will thank you [2] if you port any of the missing plugins to the new codebase in the 06-api branch:
[MM 0.6] Plugins

If you have free time, NetworkManager installed [3] and basic GLib/GIO development knowledge, ModemManager developers will thank you [4] if you help providing support for the new ModemManager1 interface in NetworkManager:
[MM 0.6] NM integration

[1] You’ll get one beer for free if we ever meet.
[2] You’ll get two beers for free if we ever meet.
[3] This already leaves out Jose, Luca and Alfred.
[4] You’ll get three! beers for free if we ever meet.

The slides of my talk about LTE and ModemManager in FOSDEM are now online at the Lanedo articles website:

• LTE is here and ModemManager is (almost) ready for it

Only some days left for FOSDEM 2012; which this [1] year is organized in Brussels (Belgium).

For anyone interested, I’ll be giving a talk about LTE and ModemManager in the Telephony devroom (room H.2213), in the best time slot possible: Sunday 5th at 09:00 am. If you wake up that early just to attend the talk, you’ll get cookies for free!! [2].

Some GNU hackers will also attend the conference, but this year there won’t be a GNU devroom. If you want to suggest a place for dinner on Friday or Saturday, please do so in the ghm-discuss mailing list.

Cheers and see you there!

[1] (and every)
[2] no, this is not true

So, after a few strives during the last year, the multitouch Xorg patches were posted and merged to master last month, making multitouch available in the upcoming Xorg release. This turns the multitouch GTK+ branch into a suitable candidate for GTK+ 3.4, which obviously deserves a video demoing what’s up there:

Hopefully soon in master, very soon…

We’re currently looking for anyone who has LibreOffice experience and is interested in working on the project. If that sounds like something you would like to do, get in touch with us.

Additionally, if you or anyone you know has experience running an open source business, please get in touch. We’re looking for someone that could facilitate a CEO type position.

I’ve been home a week from the LibreOffice Conference in Paris and from a personal point of view, it was a huge success.

First of all, here are my slides from the short talk I gave about what we achieved with libvisio over the duration of Google Summer of Code. There is still work to be done but once end-user feedback starts coming in, we can sand down any rough edges.

The conference was a lot of fun, particularly the company. I had the pleasure of meeting the rest of the libvisio team, Fridrich Strba and Valek Filippov, who looked out for me the whole time I was there. I’m sure the Paris pickpockets are still cursing their names.

I also have to admit to being a little starstruck at meeting all the fantastic hackers whose work I have made so much use of. The LibreOffice team were a diverse, interesting and kind bunch who put up with my incessant (well-meaning) questions with good grace and gave me plenty to think about on coding, the universe and everything.

It was wonderful to be surrounded by programmers and Linux users without the geekier-than-thou attitude. Despite being younger (and greener) than most and female unlike many (with a few notable exceptions), I chatted away to my fellow hackers without once feeling patronised.

Finally, I’m staying out of the whole political situation – I started coding with LibreOffice for pragmatic reasons (I could get the code easily, Easy Hacks make getting to know the project simpler and LibreOffice was part of GSoC ’11). However, I think the conference really confirmed for me that as important as the code base is, the community that surrounds a project this size is as vital. Without their helpful, inclusive approach, I’d have found contributing to an open source project of that magnitude an insurmountable task.

So here’s to another year!

Last week I attended the first LibreOffice conference in Paris together with the Lanedo LibreOffice hackers. Lionel Dricot gives a nice summary of the buzz at the conference in his latest blog post.

I figured I had to put the new crazy-fast machine Lanedo bought me to use at this conference, so I decided to attempt to build LibreOffice using Clang on Mac OS X. My expectation was that this would be too large a task for a single weekend, but to my surprise I managed to get to a completed build during the very last minutes of the conference. Unfortunately, the resulting executable crashes on start up :) So there’s still some work to be done.

The patches that were needed to complete the build have been submitted and I wrote up a wiki page about the remaining issues. See the mailing list post and the “Building LibreOffice with Clang” wiki page.

In the near future, I hope to fix things so that the resulting executable will actually launch and work correctly. Also, it should be interesting to try to compile LibreOffice using Clang on Linux (faster builds! warnings that a human can actually understand!).

Just like the LibreOffice conference, this tiny project has been good fun :)

Effective immediately I will be reachable at kris (at) loopnest.org instead of my old gtk.org alias (or in addition to gtk.org when gtk.org mail comes online again). The e-mail address attached to my Bugzilla accounts will be changed in the coming days as well.

I will not be rewriting my e-mail address in commit history, but will start committing with my e-mail address from today on.

Given there have been a number of improvements to tracker-needle recently, I thought I would make a video to highlight some of them. A quick summary:

• Searching for “foo” now finds files tagged with “foo”
• Searches are limited to 500 items per category/query (to avoid abusing the GtkTreeView mainly)
• A tag list is now available to show all hits by tags
• Tags can be edited by the context menu per item (planned to be improved later)

Really nice to have tagging supported properly in tracker-needle now.

(Image: Mag3737)

And here’s another muffin from the code cake factory…

About Testbit Tools
The ‘Testbit Tools’ package contains tools proven to be useful during the development of several Testbit and Lanedo projects. The tools are Free Software and can be redistributed under the GNU GPLv3+.

This release features the addition of buglist.py, useful to aid in report and summary generation from your favorite bugzilla.

Downloading Testbit Tools
The Testbit Tools packages are available for download in the testbit-tools folder, the newest release is here: testbit-tools-11.09.0.tar.bz2

Changes in version 11.09.0:

Feedback

If you find this release useful, we highly appreciate your feature requests, bug reports, patches or review comments!

See Also

1. The Bugzilla Utility buglist.py – managing bug lists
2. Wikihtml2man Introduction – using html2wiki

Before it’s Christmas again, I should blog about the nifty hack I did last Christmas, already nine months ago.

Often, I am quickly coding up test cases. Compiling and running usually goes like this (insert cheering after successful compile):

$ clang `pkg-config --libs --cflags gtk+-3.0` -o test/foo3 test/foo3.c
$ ./test/foo3  

(foo3:84880): GLib-GObject-WARNING **: g_object_set_valist: object class `GtkWindow' has no property named `width'

(foo3:84880): GLib-GObject-WARNING **: gsignal.c:2293: signal `delet-event' is invalid for instance `0x101865000'

And insert a sigh of disappointment after witnessing the GObject warnings. I figured that with all the GObject Introspection work going on, it would be quite nice to teach the compiler about GObject Introspection. So while snow was pouring down last Christmas, I hacked up a quick and dirty clang plugin. It looks like this:

$ clang -cc1 -fcolor-diagnostics `pkg-config --cflags gtk+-3.0` -load libGObjectHelper.dylib -plugin gobject-helper test/foo3.c
test/foo3.c:23:25: warning: object 'GtkWindow' has no property 'width'
  g_object_set (window, "width", 320, "height", 240, NULL);
                        ^
test/foo3.c:23:39: warning: object 'GtkWindow' has no property 'height'
  g_object_set (window, "width", 320, "height", 240, NULL);
                                      ^
test/foo3.c:24:29: warning: object 'GtkWindow' has no signal 'delet-event'
  g_signal_connect (window, "delet-event",
                            ^
3 warnings generated.

One of the features I wanted to add before blogging, was to also use the clang-style spelling corrections. For the last warning, it would say "did you mean ‘delete-event’?" Of course, there’s still much more to do than that to make the plugin feature complete.

This plugin will not work just with GTK+ source code. Because it’s using GObject Introspection data, it should work for any GObject library for which the GObject Introspection data has been generated.

The code is not ready for public consumption, so I am not releasing it just yet. My plan is to find time in the very near feature once my critical bugs are under control (or worst case during Christmas again :) and work on bringing the plugin into shape and trying it out on some larger examples. See below why trying it on larger examples first is quite important to figure out whether this plugin will ever be useful for the general public. When that is done, I plan to dump it in a public git repository for all to enjoy.

So, how does it work?

At its very core, the plugin walks over the Abstract Syntax Tree (AST) produced by clang. For the above example we simply handle calls to g_signal_connect_data and g_object_set. In order to verify whether the given signal or property name exists, we need to know the exact type of the object we are calling this function on. This is a problem that cannot always be solved.

What the plugin can currently do to solve this problem, is to determine where exactly the object pointer is assigned in the same function. If the object pointer is a GtkWidget *, we could at least assume that the object contains all signals and properties belonging to GtkWidget objects. In the next line, it is possible that the value of a call to gtk_label_new() is assigned to the object pointer. In this case we know the object is of type GtkLabel and as a result we can catch more errors.

The above strategy works fine on simple examples. The challenge is to make this work for larger programs. It might be a reasonable assumption to say that often an object is created, properties set and signals attached in the same function. However, there might be many cases where an object is created in a separate function and only a GtkWidget * type is returned. When the function is in the same compilation unit, it will still be possible to find out the full type though.

It is already clear that the plugin will never be able to catch all errors. Still I expect it to be pretty helpful. Another case which is interesting to handle is the following:

GtkWidget *widget;

if (can_edit)
  widget = gtk_entry_new ();
else
  widget = gtk_label_new ();

g_object_set (widget, ...

We will never be able to report all possible errors in this case. For example, if widget is assigned a GtkLabel and we use a property from GtkEntry, we cannot catch it. What we can do is tag the widget variable with both the GtkLabel and GtkEntry types and put out an error if a property or signal is used that is neither in GtkLabel nor in GtkEntry.

Why not just program in a higher-level language, then you would not need a plugin like this?

Good question.

To be continued …

ANSI to HTML conversion courtesy of a2h

Something I have been meaning to do for a long time, is to update the preferences dialog for Tracker to easily add locations which are special user directories (as per the GUserDirectory locations).

I wanted to do this in such a way that:

• It was really easy to toggle locations as recursive or not
• The file chooser was only necessary for non-standard locations
• Better use of the space was made by integrating the two lists (previously) for single directory and recursive directory indexing
• I could fix a few issues which had been reported when it came to saving using the special symbols (e.g. &DESKTOP for G_USER_DIRECTORY_DESKTOP, etc.) when one or more user directories evaluated to the same location

The result is this (now in master and 0.12.2 when it is released):

Given we (the tracker team) want to try to fit into the GNOME schedule for 3.2, we decided to bring the release of 0.12.0 ahead early. The roadmap is mostly complete anyway.

The official announcement can be seen here.

Thank you to everyone involved!

Recently I also updated the GtkSearchEngineTracker implementation to not use hacky dlopen() calls and to use DBus instead. This avoids us updating the work for each new version of Tracker that comes along too. The patch attached to the bug (658272) should be applied soon (given Matthias was pushing for this sooner rather than later). So, we’re all on track!

Last Thursday I merged the Apple Filing Protocol (AFP) backend for GVfs; so we finally have support for Apple shares too now. It has been written by Carl-Anton Ingmarsson and it was his Summer of Code 2011 project. It is on the master branch and thus will be in the next unstable release. Please test it and report bugs against the “afp backend” component.

Carl-Anton did quite an impressive job – probably best depicted by the diffstat of the merge:

 client/Makefile.am            |    1
 client/afpuri.c               |  269 ++
 client/gdaemonvfs.c           |    2
 configure.ac                  |   31
 daemon/Makefile.am            |   45
 daemon/afp-browse.mount.in    |    8
 daemon/afp.mount.in           |    5
 daemon/gvfsafpconnection.c    | 1651 ++++++++++++++++
 daemon/gvfsafpconnection.h    |  420 ++++
 daemon/gvfsafpserver.c        | 1033 ++++++++++
 daemon/gvfsafpserver.h        |   85
 daemon/gvfsbackendafp.c       | 4292 +++++++++++++++++++++++++++++++++++++++++-
 daemon/gvfsbackendafp.h       |   23
 daemon/gvfsbackendafpbrowse.c |  608 +++++
 daemon/gvfsbackendafpbrowse.h |   47
 daemon/gvfsbackenddnssd.c     |    6
 daemon/gvfsjobsetattribute.h  |    1
 17 files changed, 8491 insertions(+), 36 deletions(-)

Over the last few months I have been working on a “treemodel-fix” branch, which I just merged into GTK+ as announced on gtk-devel-list. Two commits in February of this year touched the row-deleted handling of GtkTreeModelFilter and GtkTreeModel:row-deleted documentation (0c3da06 and f632956). When exactly GtkTreeModel:row-deleted should be emitted has always been a nasty inconsistency amongst models (I wrote about it in May 2007, which turned out to be wrong), so my interest was sparked into really trying to understand this inconsistency and how to fix it.

This resulted in the “treemodel-fix” branch, which I could only start working on in May this year. After I finally solved the GtkTreeModel:row-deleted issue for real (details will be in my next blog post), I decided it would be good to also solve problems in another area which has never been 100% clear to me: reference counting GtkTreeModelSort and GtkTreeModelFilter. I brought these under unit test and fixed any issue I could find, which took much longer than I expected. And finally, after adding quite some unit tests, I now dared to review and apply a couple of GtkTreeModelSort/GtkTreeModelFilter patches which were waiting in Bugzilla.

The code is now in the master branch and will end up in GTK+ 3.2. For heavy users of GtkTreeModelSort/Filter, this would be a good time to test your code against GTK+ from master and report any regressions you may encounter. If things look good, I will consider merging the branch in GTK+ 2.24 as well in 1 to 2 months from now.

It has been 9 years since I first started working on GtkTreeModelSort and GtkTreeModelFilter. Finally having the feeling that you fully understand what is going in these pieces of code is an interesting one after so many years ;) To make sure this knowledge does not get lost, I wrote extensive documentation containing most of what I’ve learned in the last months, which has been committed as part of the branch (see files gtktreemodel.c, gtktreemodelfilter.c, gtktreemodelsort.c). I will also run a series of blog posts on the matter, covering:

• The real story behind GtkTreeModel::row-deleted
• Reference counting in GtkTreeModel
• Improved performance in GtkTreeModelSort and GtkTreeModelFilter
• Limitations on visible functions in GtkTreeModelFilter

Recently Adrien Bustany blogged about the Firefox extension for Tracker and has yet to blog about his Thunderbird extension work.

As you would expect, the Firefox extension syncs bookmarks to Tracker (in that direction only for now) and the Thunderbird extension sends email to Tracker to be indexed (even full text content of emails which our Evolution miner doesn’t do because of the system stress it causes). This is really quite superb work from Adrien and tracker-needle already supports bookmarks and emails so it all just works after a make install (into the $prefix where Firefox/Thunderbird are installed). Currently the Thunderbird extension requires version >= 5.0 (works with betas too), and the Firefox extension requires version >= 4.0 (and supports 5.0).

These works have been imported using a pretty cool tool after I felt more comfortable using that to import Adrien’s subtrees into Tracker’s git repository. I did read up on the coolest merge ever from Linus but it felt more like a hack to me to do it that way. Still, I guess Linus knows what he is doing

So now we have both plugins imported with full history into git. The thunderbird branch was merged to master today and the firefox branch will be merged this week hopefully pending Adrien’s review. Great stuff!

So, I have finally made progress that isn’t so ground-breaking that my mentor wants to write about it but is big enough that certain people will stop making fun of my empty blog. So, frob (his wonderfully useful work can be found here), I hope you’re happy.

I’ve been working on shapes, lines and their properties, most recently on fills. Here’s how it’s going so far (Visio document on top, my output below).

Thanks to frob for the image, plus animated gif.

A few technical details for those who care: Visio draws shapes (including rectangles) as individual lines and before they can be filled, so we have to manually detect whether or not it’s a closed polygon. At the moment, we simply take the first point and compare it to the last point and make sure there are no gaps in between. It works for most simple cases but since when are things ever truly simple when reverse engineering?

You may also notice a difference between how gradients 31-34 are drawn in Visio vs my output. There’s no direct equivalent of this type of square gradient that I know of in the SVG or ODG specifications, so we’re approximating it. I have a whole new appreciation of slight imperfections when porting documents to different formats.

In the time it has taken to write this, I’ve already found that some of what I’ve written about will change. This is why I’m a programmer not a blogger ;)

I have blogged about this from the official GTK+ blog too, but I wanted to really say personally how happy I am that this is done now. Really great work from Devin Samarin especially with the gtk-doc integration which looks like an extension of the main website instead of a separately maintained project.

If anyone has any comments on how to improve the content, don’t hesitate to get in touch with me, Devin Samarin or Javier Jardón (who also has been helping out on the website side more recently).

Earlier today I’ve pushed gedit-cossa, a plugin for gedit to help writing CSS for GTK+ themes, it is able to display a number of samples, loaded from GtkBuilder files.

Here’s a video demonstrating how it works:

Cossa is still in pretty early development stages, immediate plans include:

• Hooking CSS parsing errors to the gedit view
• Adding a lot more samples, these should range from simple examples (basic widgets in different states) to complex (basic main window sample, preferences dialogs, …)

Anyone is welcome to help, specially in the second point, as it is fairly straightforward to add new samples.

What’s this?
Wikihtml2man is an easy to use converter that parses HTML sources, normally originating from a Mediawiki page, and generates Unix Manual Page sources based on it (also referred to as html2man or wiki2man converter). It allows developing project documentation online, e.g. by collaborating in a wiki. It is released as free software under the GNU GPLv3. Technical details are given in its manual page: Wikihtml2man.1.

Why move documentation online?
Google turns up a few alternative implementations, but none seem to be designed as a general purpose tool. With the ubiquituous presence of wikis on the web these days and the ease of content authoring they provide, we’ve decided to move manual page authoring online for the Beast project. Using Mediawiki, manual pages turn out to be very easily created in a wiki, all that’s then needed is a backend tool that can generate Manual Page sources from a wiki page. Wikihtml2man provides this functionality based on the HTML generated from wiki pages, it can convert a prerendered HTML file or download the wiki page from a specific URL. HTML has been choosen as input format to support arbitrary wiki features like page inclusion or macro expansion and to potentially allow page generation from other wikis than MediaWiki. Since wikihtml2man is based purely on HTML input, it is of course also possible to write the Manual Page in raw HTML, using tags such as h1, strong, dt, dd, li, etc, but that’s really much less convenient to use than a regular wiki engine.

What are the benefits?
For Beast, the benefits of moving some project documentation into an online wiki are:

• We increase editability by lifting review requirements.
• We are getting quicker edit/view turnarounds, e.g. through use of page preview functionality in wikis.
• We allow assimilation of user contributions from non-programmers for our documentation.
• Easier editability may lead to richer documentation and possibly better/frequently updated documentation.
• Other projects also seem to make good progress by opening up some development parts to online web interfaces, like: Pootle translations, Transifex translations or PHP.net User Notes.

What are the downsides?
We have only recently moved our pages online and still need to gather some experience with the process. So far possible downsides we see are:

• Sources and documentation can more easily get out of sync if they don’t reside in the same tree. We hope to be mitigating this by increasing documentation update frequencies.
• Confusion about revision synchronization, with the source code using a different versioning system than the online wiki. We are currently pondering automated re-integration into the tree to counteract this problem.

How to use it?
Here’s wikihtml2man in action, converting its own manual page and rendering it through man(1):

  wikihtml2man.py http://testbit.eu/Wikihtml2man.1?action=render | man -l -

Where to get it?
Release tarballs shipping wikihtml2man are kept here: http://dist.testbit.eu/testbit-tools/.
Our Tools page contains more details about the release tarballs.

Have feedback or questions?
If you can put wikihtml2man to good use, have problems running it or other ideas about it, feel free to drop me a line about it. Alternatively you can also add your feedback and any feature requests to the Feature Requests page (a forum will be created if there’s any actual demand).

What’s related?
We would also like to hear from other people involved in projects that are using/considering wikis to build production documentation online (e.g. in manners similar to Wikipedia). So please leave a comment and tell us about it if you do something similar.

See Also

1. New Beast Website – using html2wiki
2. The Beast Documentation Quest – looking into documentation choices

Like every year, I am driving to Berlin this week to attend LinuxTag 2011 to attend the excellent program. If you want to meet up and chat about projects, technologies, Free Software or other things, send me an email or leave a comment with this post and we will arrange for it.

A few days ago I merged the first part of the CoreText backend into Pango’s master branch, after bitrotting on my disk for a full year (apologies for that). The upside is that it also got a year of testing on my machine :) The CoreText backend is enabled by default on machines running Mac OS X 10.5 or higher and used instead of the older ATSUI backend. Because the older ATSUI API has been deprecated since Mac OS X 10.5, and more importantly because the ATSUI API is not fully available in 64-bit mode on Mac OS X 10.6, we were in need of this CoreText backend. When using GTK+ on Mac OS X 10.4, nothing changes, since CoreText is not (publicly) available on these systems.

So far, the CoreText backend was mostly based on the existing ATSUI code, so it should be working nicely for most people. If not, you are welcome to file bugs in the new coretext component in the Pango module in GNOME bugzilla.

There is one missing piece and that is also where the CoreText backend’s structure is going to deviate from the ATSUI backend. The ATSUI backend has never been really good at handling font fallbacks and fonts for non-Latin languages (see 608929). This is one of the things I want to get right in the CoreText backend and will be the second part of this project. I do have some things in place in a local branch on my disk, but it is not working yet as it should. Hopefully, I can find some spare time in the coming months to finish this. Progress can be tracked in bug 647969.

Though up first is a context switch back to GTK+ to review and fix a couple of things around GtkTreeModelFilter, GtkTreeModel’s row-deleted signal and to further extend the unit tests in this area.

BEAST/BSE version 0.7.4 is available for download at:

• http://beast.testbit.eu/_dist/beast/v0.7/
• This release integrates the bse-alsa driver for which no seperate package is now needed.

BEAST is a music composition and modular synthesis application released as free software under the GNU LGPL that runs under Unix. Refer to the About page for more details.

The 0.7.4 release integrates the bse-alsa package, several speedups, important bug fixes and translation updates.

Please feel free to provide useful feedback or contribute on IRC, the mailing list and in the Wiki.

TRANSLATORS: Please help us to improve the BEAST translation, just download the tarball, edit po/.po and email it to us or submit translations directly via the Beast page at Transifex.

Overview of Changes in BEAST/BSE 0.7.4:

• Renamed the project to Better Audio System / Better Sound Engine
• Moved project website to: http://beast.testbit.eu/
• Various build system fixes [stw,timj]
• License fixups for some scripts [stw]
• Fixed subnormal tests on AMD64 if SSE unit is in DAZ mode [stw]
• Replaced slow resampler checks with a much faster resampling test [stw]
• Performance improvements for various tests [stw]
• GLib 2.28 unit test porting [stw]
• Speed improvements for record field name [stw]
• Fixed XRUNs in ALSA driver on 64bit systems [timj]
• Added beast.doap [Jonh Wendell]
• PO handling improvements.
• Updated German translation.
• Updated Norwegian bokmål translation [Kjartan Maraas]
• Added e-Telugu translation [Veeven]

(Image: Salvatore Vuono)

 

The self deceiving assumption of effective human multitasking.

People are often telling me they are good at multitasking, i.e. handling multiple things at once and performing well at doing so. Now, the human brain can only make a single conscious decision at a time. To understand this, we need to consider that making a conscious decision requires attention, and the very concept of attention means activating relevant information contexts for an observation or decision making and inhibiting other irrelevant information.

The suppression involved in attention control makes it harder for us to continue with a previously executed task, this is why interruptions affect our work flows badly, such as an incoming call, SMS or a door bell. Even just making a decision on whether to take a call already requires attention diversion.

Related, processing emails or surfing while talking to someone on the phone results in bad performance on both tasks, because the attention required for each, necessarily suppresses resources needed by the second task. Now some actions don’t suffer from this competition, we can walk and breathe or balance ourselves fine while paying full attention to a conversation. That’s because we have learned early on in our lives to automate these seemingly mundane tasks, so they don’t require our conscious attention at this point.

Studies [1] [2] have shown time and again, that working on a single task in isolation yields vastly better results and in a shorter time frame when frequent context switches are avoided. This can be further optimized by training in concentration techniques, such as breath meditation, autogenic training or muscle relaxation.

Here’s a number of tips that will help to put these findings to practical use:

1. Let go of the idea of permanent reachability, nothing is so urgent that it cannot wait the extra hour to be handled efficiently.
2. Make up your own mind about when to process emails, SMS, IM, news, voice messages.
3. Start growing a habit of processing things in batches, e.g. walk through a list of needed phone calls in succession, compose related replies in batches, first queue and later process multiple pending reviews at once, queue research tasks and walk through them in a separate browsing session, etc.
4. Enforce non-availability periods where you cannot be interrupted and may concentrate on tasks of your choice for an extended period.
5. Schedule phone meetings in advance, ensure everyone has an agenda at hand for the meeting to avoid distractions (Don’t Call Me, I Won’t Call You).
6. Deliberately schedule relaxation phases, e.g. take a 5 minute break off the screen per hour, ideally moving and walking around; rest breaks are needed after 90 minutes at latest.

Just a quick reminder: The student application period for the Google Summer of Code 2011 has opened as of yesterday (Monday, the 28th of March). Apply now! The starting point for Gnome is here; it has all the relevant information.

In addition to that, if you are happen to be interested in Neuroscience and Informatics the International Neuroinformatics Coordinating Facility (INCF) also got accepted as a organization (Thanks Raphael!). Among other very interesting project ideas there are also two proposals that are Gnome related (as in pygtk based applications). If you have a cool Neuroinformatics+Gnome based idea be sure to apply at the INCF. The starting point is here.

Along the last days/weeks, I’ve gave myself the oportunity to tinker with XInput 2.1 in GTK+, now that the core concept of the involved changes seem settled (although corner cases are still being discussed).

Thanks to the previous port to XInput 2.0, handling multitouch events has been fairly easy, by enabling GDK_TOUCH_MASK events on your widget you can receive GDK_TOUCH_PRESS/MOTION/RELEASE events containing a touch ID, which is unique at that time for a touch event stream, so enabling that you can effectively receive events from simultaneous touches.

In addition, one can create GdkTouchClusters (related to a GdkWindow) and add touch IDs to it. from that point on, any update on these touch IDs stops sending individual GDK_TOUCH_MOTION events, instead sending GdkEventMultiTouch events, containing all latest events for the touch IDs in a GdkTouchCluster.

I’m pretty happy with the resulting API, althought there are some internal details left to improve, my main gripe currently is that implicit grabs in CSW still happen per device, this means no multi-widget multitouch yet within an app (also posing interesting problems with keyboard events redirection and explicit grabs). Another big item is looking into integrating this with gestures, as direct manipulation and gesturing need to go hand in hand, so that branch could be discontinued in favor of this one.

As I’m pretty lazy, and the results would be strikingly similar to what I previously posted, I won’t post any video, so you’ll have to settle for a screenshot:

This is sitting now in the xi21 branch. If you just compile this you won’t see much working though, the demo only reacts to touch events, which are only sent if XInput 2.1 is there, which requires compiling certain Xorg modules branches, and having a multitouch device at hand.

Fixing the default GNOME3 theme

Now that most of GTK+ widgets are using GtkStyleContext, I finally got onto improving the default gnome3 theme/engine, I finally chose to rip off the tiny clearlooks engine bits I needed to demonstrate how minimal engines can complement and extend the current CSS theming features. So things are getting closer to the mockups:

There are some things that still need to be improved, column headers and expanders most namely, but things should be mostly there pretty quickly. Even though, hands and eyes are most welcome on both the CSS file and the engine.

A gestures interpreter for GTK+
Despite what some might think, my day to day work carries me quite far from theming land, during the last week I got the oportunity to start development on a gestures interpreter for GTK+, a pretty interesting (read: wacky ) piece of dynamic programming, that seems to work pretty well for its builtin gestures (Video here, at the moment it handles swiping in the 4 directions, plus circular swipe in both directions)

This code lives at the moment in a GTK+ branch, including a testcase. The gestures interpreter at the moment handles individual pointer movements separatedly, although it may be improved over time to handle multiple input pointers, as the interpreter itself is private and widgets just get an enum for the gesture type.

As the stock gestures could be stored in terms of coordinates or vectors, future plans include having these stored in a mmap()-able format, plus having an editor to create new gestures.

For those building gnome3 frequently from git or paying attention to gtk-devel, this might be old news, but still worth mentioning… The gtk-style-context branch has landed in GTK+ master, which will quickly unveil a powerful theming system, powered by CSS files.

Boring by default, yet versatile

Although some apps (mostly these implementing widgets themselves) might undergo some work to adapt to this, there are API docs and migration documents (mostly courtesy of Matthias, who’s done an excellent work) that should ease the task.

Besides the GTK+ work, there is also both a gnome3 theme and engine using the new stuff. Things are still ongoing here, as many things can be leveraged into CSS, which would leave the engine very little things to do. Andreas started looking at some point into the branch, so he might have some things ready in that field .

But not only that! Carlos Garcia Campos (KaL) has been doing good progress on webkit-gtk so no backing widgets creation is needed, and Paolo Borelli has ported GtkSourceView as well, awesome!

On this weekend I’ve returned from the GTK+ Hackfest in A Coruña. All in all, it’s been a really intensive event, so much that apparently many of us have been to exhausted to blog , there have been lots of ideas and interesting topics to discuss about, and lots of goodness have landed in git (GPeriodic, GtkGrid, input/output windows removal, GdkRGBA, …). Most importantly, a roadmap is taking shape!

Personally, I’ve been working during the past week on the gtk-style-context branch, adding some missing features and improving how things render in general. In that branch, you could see something somewhat boring, as we are accustomed to:

But then with this CSS in ~/.gtk-2.0.css:

.background {
    background-color: rgba (0.2, 0.2, 0.2, 0.9);
}

.button {
    border-radius: 5;
    border-width: 1;
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (@bg_color, 1.3)),
                                     color-stop (0.55, shade (@bg_color, 1.1)),
                                     color-stop (0.55, shade (@bg_color, 0.9)),
                                     to (@bg_color));
}

GtkButton:hover {
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (@selected_bg_color, 1.3)),
                                     color-stop (0.5, shade (@selected_bg_color, 1.1)),
                                     color-stop (0.5, shade (@selected_bg_color, 0.7)),
                                     to (@selected_bg_color));
    transition: 200ms ease-in-out;
}

GtkBox > GtkBox > GtkButton {
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (rgba (0.2, 0.2, 0.2, 0.8), 1.3)),
                                     color-stop (0.55, rgba (0.4, 0.2, 0.2, 0.8)),
                                     color-stop (0.55, rgba (0.6, 0.2, 0.2, 0.8)),
                                     to (rgba (0.3, 0.3, 0.3, 0.8)));
}

GtkScrolledWindow {
    background-color: rgba (0.3, 0.3, 0.3, 0.7);
}

.trough,
.slider {
    border-radius: 3;
    border-width: 1;
}

GtkBox > GtkLabel {
    font: Sans 15;
    foreground-color: #f00;
}