Planet Collabora

I spent some free time today getting caught up on the large backlog of phonon-gstreamer bugs. Towards the end, I started to have delusions of grandeur: Imagine a phonon-gstreamer codebase that doesn’t require supporting a zillion different audio frameworks, and instead belays that task to something that I don’t have to maintain.

My question here, is how many people would throw a fit if phonon-gstreamer dropped support for ALSA and OSS, and forced everyone to use pulseaudio by way of GStreamer’s excellent pulseaudio support?

Hold on, lower your pitchforks for a minute. Let us consider the audio framework landscape in the modern world:

• Pulseaudio is the One True Way for audio playback in Gnome
• For 90% of the support questions we handle in #kde-multimedia, the solution is “use pulseaudio”.
• Pulseaudio can handle using OSS, ALSA, Bluetooth, or whatever your audio output is, through one consistent entry point
• It is a total headache to figure out any bugs in your audio when music goes from Amarok->Phonon->Phonon-GStreamer->(ALSA, OSS, Pulseaudio, god knows what)->Speakers->Earholes

Additionally, I really don’t feel like testing phonon-gstreamer on all those different kernel-level interfaces with exotic setups every time I fix a bug and am afraid I’d introduce another twelve. The PulseAudio folks seem to do a fantastic job at that already. Phonon isn’t meant for real-time playback or production studio quality audio. Thats what Jack is meant for.

I can’t think of a good reason why we shouldn’t stand on the shoulders of giants by making PulseAudio handle all the hard stuff on Unix involving massaging PCM formats, equalizers, matching playback category with output device, enumerating outputs both real and virtual, volume control, etc.

If you can, leave a comment on this post. I’m not making an official statement saying that I’m definitely removing ALSA and OSS support from phonon-gstreamer, I’m merely asking for feedback to see what can be done to fix things at all levels in the audio stack.

Continuing with my previous post about the Zeitgeist team’s improvements with regards to speed, there’s a nifty tool in the sources I wrote yesterday that uses a genetic algorithm to find the slowest queries you can throw at the engine.

If you’re not familiar with genetic algorithms, here’s a brief review of how they work:

• Start off with an array of numbers, with each index corresponding to a particular attribute of the problem.
• Evaluate the fitness of that genome
• Simulate evolution of the successful genomes by crossing, mutations, etc, just as you would with real DNA chromosomes

In the case of this Zeitgeist tool, the chromosome refers to a query, and each allele (index of the array) refers to an attribute of the query. Here’s a relevant comment from the sources:

# Chromosome to data mapping:
# 0, 1 - Timerange begin and end. If both are zero, we use timerange.always()
# 2 - The search type. Anything over 30 is a dead individual.
# 3-5 - Specify template properties. Anything besides 0 and 1 is dead.
# 3 - Specify a subject interpretation
# 4 - Specify a subject manifestation
# 5 - Specify an event actor

Using the super cool pyevolve library, implementing a genetic algorithm is super easy:

def eval_func(chromosome):
  query = buildQuery(chromosome)
  if query is None:
    return 0

  start = time.time()
  results = engine.find_events(*query)
  overall = (time.time() - start)
  return (results["find_events"]*2+results["find_event_ids"]*4+results["get_events"])*1000

genome = G1DList.G1DList(6)
genome.evaluator.set(eval_func)
ga = GSimpleGA.GSimpleGA(genome)
ga.evolve(freq_stats = 1)
query = buildQuery(ga.bestIndividual())
assert query is not None
print query, len(engine.find_events(*query))

Let it run for a long while on a big database, and you end up with a query that takes forever. Due to how evolution works, it isn’t the longest running query, but it is certainly one that takes a long time.

The Zeitgeist team has been hard at work lately. We recently moved from Launchpad and Bzr to freedesktop.org and git, just in time for the 0.9 release. Since then, Seif and I have been hammering away at making a bunch of speed improvements and trying to scale the engine to be able to handle a few billion events just as fast as it can handle a few hundred thousand.

Our first experiment has been focusing on the sqlite indexes. This one index tweak appears to increase our benchmark speeds by almost 45%:

CREATE INDEX event_timestamp_subj_interp_subj_id_id
                   ON event(timestamp, subj_interpretation, subj_id, id)

And here’s the graph to prove it:

Shorter lines are better. Blue is the 0.9 release, and the orange is the tiny index change. All of our raw data is in this google spreadsheet, so feel free to have a look. I can’t guarantee that you’ll immediately understand the information, but I’m open to explain it to those interested.

 

That’s right, it’s finally out! Thanks go out to all our contributors for the great work (there’s too many — see the shortlog!). The highlights of the release follow. Head over to the announcement or release notes for more details.

• Dynamic sample rate switching by Pierre-Louis Bossart: This makes PulseAudio even more power efficient.

• Jack detection by David Henningsson: Separate volumes for your laptop speakers and headphones, and more stuff coming soon.

• Major echo canceller improvements by me: Based on the WebRTC.org audio processing library, we now do better echo cancellation, remove the need to fiddle with the mic volume knob and have fixed AEC between laptop speakers and a USB webcam mic.

• A virtual surround module by Niels Ole Salscheider: Try it out for some virtual surround sound shininess!

• Support for Xen guests by Giorgos Boutsiouki: Should make audio virtualisation in guests more efficient.

Special thanks from me to Collabora for giving me some time for upstream work.

Packages are available on Gentoo, Arch, and probably soon on other distributions if they’re not already there.

Once upon a time, three intrepid individuals made Empathy publish your location to your contacts, and show your contacts’ locations on a map. Today, I noticed that the Location tab is missing from Preferences—I guess Debian’s Empathy is built without GeoClue support for some reason—and as a result the map looks rather forlorn, what with none of my contacts publishing their location:

A map is an obvious demo to build, but I don’t think it’s that useful (even when it had more than zero contacts on it, I never looked at it).¹ So what would be more useful? For starters, here’s some “relevant art” from Skype, showing a contact’s local time in their tooltip:

Adding that to Empathy might be a useful first step. But unlike Skype, it’s possible to use this information outside the IM app. So, if I spend a lot of time chatting to friends in Melbourne and New York, why not automatically add those timezones to GNOME Clocks? (The last two mock-ups in that section look particularly bare—perhaps the names of some contacts could show up in the space where “local time” does for Boston.)

For this to be useful, of course, someone would have to fix the publishing of location information in the first place. But if fixing it produced a more compelling feature than a map, it would not be such a thankless task.

1. Top designers agree! To quote Allan Day, “I could live without contacts on a map ”.

I was replying to an email, and got side-tracked into writing some Wayland anti-FUD. There are lots of myths about Wayland out there, so I thought to better make it into a blog post.

This post is about the very small overhead of a Wayland (system) compositor, and why Wayland over network will be much better than X-over-ssh.

I predict that on desktops and other systems that may have accounts for more than one person, there will actually be two Wayland compositors stacked. There is a system compositor at the bottom, handling fast user switching, replacing VT switching, etc., and then a session compositor that actually provides the desktop environment. This is not my idea, it has been written in the Wayland FAQ under "Is Wayland replacing the X server?" for a long time.

My point is: Wayland compositors will not make 3D games suck because of compositing. While explaining why, I also continue to explaining why network transparency will not suck either. Now, do not mix up these things, I am not claiming that remoting 3D games over network will magically become feasible.

The overhead of adding a system compositor in the Wayland stack will be very small. A system compositor normally does not do any real work for compositing, it only takes the buffer handle from a client compositor, and flips it onto the screen. No rendering and no image copying involved in the system compositor.

It is the same with a full-screen game vs. any Wayland compositor: the compositor will not do any real work. A game renders its image into a buffer, passes the buffer handle to the compositor, and the compositor tells the hardware to scan out the buffer. No extra copying, no extra rendering.

The overhead that will appear with adding a system compositor, is relaying input events and buffer flips. The amount of data is small, and at least buffer flips will happen at most once per vertical refresh per monitor. There is also the idea of relaying input events only once per frame. This means that CPU process context switches will increase only by few per frame, when adding another compositor in the stack. Ideally the increase is 2 per frame: a switch to system compositor, system compositor handles input and output, and a switch back.

The overhead can be this small, because the protocol has been designed to avoid round-trips. A round-trip means that one process is waiting for another to reply before it can continue. The protocol also favors batching: accumulate a bunch of data, and then send as a batch. Both of these principles minimize the number CPU process context switches.

Because of these design principles, no Wayland developer is worried about the performance of a possible network transparency layer. Minimizing CPU context switches translates directly to minimizing the effect of network latency. Some believe, that even a simple Wayland network transport which practically just relays the Wayland protocol messages as is, and adds transferring of buffer data, will clearly outperform the traditional X-over-ssh.

Now, if you still claim that X-over-ssh would be better, you a) underestimate the effect of latency, and b) forget that modern applications do not send small rendering commands through the X protocol like 10-20 years ago. Modern applications render their content client-side, and send images to the X server. Wayland simply makes images the only way to send content to the server, allowing to drop the whole rendering machinery from the server and avoiding a huge amount of protocol.

The wakefield RISC OS show is an event the NetSurf project has attended for a long time. in fact since 2005 when the "stand" was a name on an A4 sheet through 2006, 2007, 2008, 2009, 2010 to 2011 we have always been present.

The event has changed in that time from a large affair with many exhibitors to a small specialist interest event with a handful of stands. I took some pictures this year which give a fair impression of the event.

We were seriously considering not attending this year as 2011 had seen us barely break even on donations versus expenses to attend. However we decided that the projects annual Grey Ox Inn post event dinner was probably worth making the effort.

So we all met up in a hotel just off the M1 near Wakefield and set up our table. And although NetSurf as a project now has much more usage on other platforms we still represent the principle browser for the RISC OS platform!

We had a pleasant time, talked to a lot of users and made our expenses back in donations. Overall an amusing Saturday. Based on the size of the event and number and age of the attendees, I fear the RISC OS may be destined for the history books.

Some debts are merely financial and some easily repaid but some require repayment in kind . Few debts are more important to me personally than a favour earned by a good friend.

Several years ago, before I started this blog, I replaced the kitchen in my house. Finances were tight at the time and I had to do the entire refit with only limited professional help. Because of this I imposed upon Mark Hymers and Steve Gran to come and assist me. They worked tirelessly for three days over a bank holiday for no immediate reward.

Mark and Steve with a drill

This weekend I had the opportunity to assist Mark with his own kitchen refit and reply my debt.

Although the challenges have been different on this build they were, nonetheless present, including walls which were most definitely not square and affixing cabinets 10mm too high so the doors could not close.

We also got to make a hole for a 125mm extractor which was physically demanding and not a little tiring (Steve actually wielding the drill had a fabulous aim)

I took some photos to document the process which has resulted in an image which is positively threatening, though the two of them are nice people really!

All in all a pleasant weekend with friends, the whole favour thing was really moot, I would have done it for a friend anyway.

My employer - Collabora - has been putting some developer resources into enabling some interesting open source technologies on Android.

One of the immediate stumbling blocks we encountered was Android's build system - each project has at least one file named Android.mk - potentially more in subdirectories.  These files are parsed by GNU Make, and use Google's collection of variables and macros to define "modules".

All of the libraries we've been interested in porting so far have used autoconf for generating their Makefiles.  Not just Makefiles, of course, as autoconf also does dependency checking and creates a config.h file with a collection of pre-processor defines generated from the target environment.

The naive approach of just manually generating the Android.mk files has a few drawbacks.  All of this information is already available in various other files, and any time those files need to be changed the Android.mk files will  need updating as well, increasing the maintenance load for the project.  Further, bundling a pre-generated Android config.h with a project that doesn't exclusively target Android is somewhat unpopular, and we'd like to be able to upstream as much of this work as possible.  The cherry on top of the sundae is that building an application via the NDK sometimes requires a slightly different Android.mk than building the same library from inside the "external" directory of a full Android distribution.

I present to you the Androgenizer - A tool for automatically generating Android.mk files.  We can provide a single static top level Android.mk for a project to setup a call to configure and some environment variables for setting up pkg-config to only see our androgenized libraries instead of the build computer's local libraries. Then Android.mk target rules are added to any appropriate Makefile.am files.  These rules call androgenizer with the variables already used to generate regular Makefiles and androgenizer spits out appropriate Android.mk files.

Androgenizer tests for the environment variable "ANDROGENIZER_NDK" and if it's set it will generate Android.mk files appropriate for building an application with Google's Android Native Development Kit, otherwise it will generate files appropriate for being built as part of an android system image.

While it doesn't completely trivialize porting a library to Android - there's still a bit of work to be done setting up the static Android.mk files we need to bootstrap the build, and sometimes Android's C library is missing important functionality - it eliminates the need to maintain a second identical list of source files and takes care of handling the difference between building with NDK and building in-system.

Anyone interested can find the git repository here

And for some examples of usage, check out some of the cool work being done with it:
http://gstreamer.freedesktop.org/wiki/GstreamerAndroid_InstallInstructions
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
http://ppaalanen.blogspot.in/2012/04/first-light-from-weston-on-android.html

Gstreamer's an especially good example, as it's been ported as both an NDK built application and as an integrated set of system libraries.

Good news!
snappy is now in GNOME, and by that I mean:

• Web page: projects.gnome.org/snappy
  
• Source code: git.gnome.org/snappy
  
• Mailing list: snappy-list@gnome.org
  
• Bugzilla: bugzilla.gnome.org
  
• Live: live.gnome.org

snappy is now officially a GNOME project!
You can play with it, discuss it and report bugs all inside the GNOME umbrella... please do, no excuses!

snappy is an open source media player that gathers the power and flexibility of gstreamer inside the comfort of a minimalistic clutter interface.

Derek Foreman has finally written up a nice blog post about his Androgenizer tool, which we’ve used for porting PulseAudio, GStreamer, Wayland, Telepathy and most of their dependencies to Android.

If you’ve got an autotools-based project that you’d like to build on Android, whether on the NDK or system-wide this is really useful.

port (v):

1. Reindent and reformat.

   empathy-time: port to TP coding style

2. Update to compile against a backwards-incompatible version of an API.

   <ocrete> twi: I’m porting farstream to [GStreamer] 0.11 this week

3. Rewrite to use a different widget set and network library.

   You should port Sojourner to Qt4!

4. Reimplement in an entirely different programming language.

   Zeitgeist has been ported from Python to Vala.

5. Translate into a different data format.

   Using Semantics3’s web crawlers, we were able to get hold of the data within a half hour, after which we spent a further half hour cleaning up the data and porting it to SQL.

Some of you might’ve noticed that there has been a bunch of work happening here at Collabora on making cool open source technologies such as GStreamer, Telepathy, Wayland and of course, PulseAudio available on Android.

Since my last blog post on this subject, I got some time to start looking at replacing AudioFlinger (recap: that’s Android’s native audio subsystem) with PulseAudio (recap: that’s the awesome Linux audio subsystem). This work can be broken up into 3 parts: playback, capture, and policy. The roles of playback and capture are obvious. For those who aren’t aware of system internals, the policy bits take care of audio routing, volumes, and other such things. For example, audio should play out of your headphones if they’re plugged in, off Bluetooth if you’ve got a headset paired, or the speakers if nothing’s plugged in. Also, depending on the device, the output volume might change based on the current output path.

I started by looking at solving the playback problem first. I’ve got the first 80% of this done (as we all know, the second 80% takes at least as long ;) ). This is done by replacing the native AudioTrack playback API with a simple wrapper that translates into the libpulse PulseAudio client API. There’s bits of the API that seem to be rarely used(loops and markers, primarily), and I’ve not gotten around to those yet. Basic playback works quite well, and here’s a video showing this. (Note: this and the next video will be served with yummy HTML5 goodness if you enabled the YouTube HTML5 beta).

(if the video doesn’t appear, you can watch it on YouTube)

Users of PulseAudio might have spotted that this now frees us up to do some fairly nifty things. One such thing is getting remote playback for free. For a long time now, there has been support for streaming audio between devices running PulseAudio. I wrote up a quick app to show this working on the Galaxy Nexus as well. Again, seeing this working is a lot more impressive than me describing it here, so here’s another video:

(if the video doesn’t appear, you can watch it on YouTube)

This is all clearly work in progress, but you can find the code for the AudioTrack wrapper as a patch for now. This will be a properly integrated tree that you can just pull and easily integrate into your Android build when it’s done. The PA Output Switcher app code is also available in a git repository.

I’m hoping to be able to continue hacking on the capture and policy bits. The latter, especially, promises to be involved, since there isn’t always a 1:1 mapping between AudioFlinger and PulseAudio concepts. Nothing insurmountable, though. :) Watch this space for more updates as I wade through the next bit.

A couple of months ago, Collabora assigned me first to research and then make a proof of concept port of Wayland on Android. I had never even seen an Android before. Yesterday, Weston on Android achieved first light!

Galaxy Nexus running Weston and simple-shm.

That is a Samsung Galaxy Nexus smart phone, running a self-built image of Android 4.0.1. Weston is driving the screen, where you see the simple-shm Wayland client. There is no desktop nor wallpaper, because right now, simple-shm is the only ported client.

How is that possible? Android has no DRI, no DRM, no KMS (the DRM API), no GBM, no Mesa, and for this device the graphics drivers are proprietary and I do not have access to the closed driver source.

Fortunately, Android's self-invented graphics stack has pretty similar requirements to Weston. All it took was to write a new Android specific backend for Weston, that interfaces to the Android APIs. Writing it took roughly three days.

And the rest of the two months? I spent some time in studying Android's graphics stack, but the majority of the time sunk into porting the minimum required library dependencies, libwayland, Weston, and simple-shm to the Android platform and build environment. Simply getting the Android build system to build stuff properly took a huge effort, and then I got to write workarounds to features missing in Android's C library (Bionic). Features, that we have taken for granted on standard Linux operating systems for years. I also had to completely remove signal handling and timers from libwayland, because signalfd and timerfd interfaces do not exist in Bionic. Those need to be reinvented still.

Android has gralloc and fb hardware abstraction layer (HAL) APIs. Hardware vendors are required to implement these APIs, and provide EGL and GL support libraries. These implementations are usually closed and proprietary. On top of these is the Android wrapper-libEGL, written in C++, open source. My first thought was to use the gralloc and fb HAL APIs directly, but turned out that the wrapper-libEGL does not support using them in the application side. Instead, I was forced to use some Android C++ API (there is no C API for this, as far as I can tell) to get access to the framebuffer in an EGL-compatible way. In the end, I had to write a lot less code than using the HALs directly.

The Android backend for Weston so far only provides basic graphics output to the screen, and offers (presumably) accelerated GLES2 via EGL for the server. No input devices are hooked up yet, so you cannot interact with Weston. I do not know how to get pageflip completion events (if possible?), so that is hacked over.

Simple-shm is the only client that runs for now. There is no support for EGL/GL in Wayland clients. Toytoolkit clients are waiting for Cairo and dependencies to be ported.

The framebuffer can be used by one program at a time. Normally that program is SurfaceFlinger, the Android system compositor. To be able to run Weston, I have to kill SurfaceFlinger and make sure it stays down. Killing SurfaceFlinger also kills the whole Android UI infrastructure. You cannot even power off the phone by pressing or holding down the physical power button!

A video about simple-shm running on Galaxy Nexus:

The sources with Android build integration and other hacks can be found here:

• http://cgit.collabora.com/git/user/pq/wayland.git/log/?h=android
• http://cgit.collabora.com/git/user/pq/wayland-demos.git/log/?h=android
• http://cgit.collabora.com/git/user/pq/wayland_aggregate.git/

The wayland_aggregate is how I actually connect to the Android build system. Building is not trivial, and you cannot simply do a checkout and start compiling. You have to get the right Android tree for your device, add my local manifest (which still points to repositories on my hard drive, i.e., won't work for you), download and extract binary blobs, and whatnot. Be warned, I will rebase the above branches.

This is the beginning of pushing a Wayland stack into Android. Next I need to clean up, send stuff upstream, add input support, find out about that pageflip, reinvent signal handling and timerfd, and then move on to the second major task: supporting Wayland GL clients. I hope it is possible to implement the Wayland platform in the wrapper-libEGL.

This work is sponsored by Collabora, Ltd, and I also thank my fellow collaborans for guidance through the vast jungles of Android.

g_clear_object() has been in glib since 2.28, and now g_clear_pointer() has landed in glib master (see bug #674634).
Their typical usage is to implement GObject::dispose, or “goto out” pattern, previously you would write:

void my_dispose (GObject *obj)
{
  MyObject *self = (MyObject *) obj;
  if (self->priv->object != NULL)
    {
      g_object_unref (self->priv->object);
      self->priv->object = NULL;
    }
  if (self->priv->hash != NULL)
    {
      g_hash_table_unref (self->priv->hash);
      self->priv->my_hash = NULL;
    }
  etc...
}

or:

void some_func ()
{
  GHashTable *tmp = NULL;

  ...
  if (error)
    goto out;

  tmp = g_hash_table_new();
  ...

out:
  if (tmp != NULL)
    g_hash_table_unref (tmp);
}

But now those becomes:

void my_dispose (GObject *obj)
{
  MyObject *self = (MyObject *) obj;

  g_clear_object (&self->priv->object);
  g_clear_pointer (&self->priv->hash, g_hash_table_unref);
  etc...
}

or:

void some_func ()
{
  GHashTable *tmp = NULL;

  ...
  if (error)
    goto out;

  tmp = g_hash_table_new();
  ...

out:
  g_clear_pointer (&tmp, g_hash_table_unref);
}

As extra bonus, g_clear_object() and g_clear_pointer() are thread-safe. That means that 2 threads can clear the same pointer at the same time and it will be freed only once. I’ve heard some code needs thread-safe dispose…

Thanks to Simon McVittie for the original idea in telepathy-glib where we had tp_clear_object/pointer for years.

Yesterday I released a new version of my message notification extension for gnome-shell (3.2 and 3.4), to install it or to update it just visit its page on extensions.gnome.org.

The main feature in the new version is that it just handles notifications coming from well-known applications: Empathy, XChat, XChat-GNOME, Pidgin and notify-send. Handling the Empathy notifications is easy because they are well integrated with the shell, but the other notifications required some hack because all the applications handle notifications in different ways. I did my best to make the notifications as useful as possible, similar to the Empathy ones, but there are some small limitations.
Some of the handled applications require plugins to show notification bubbles:

• Pidgin: Click on the “Tools” menu and then “Plug-ins”. Make sure that the “Libnotify Popups” plugin is enabled. If the plugin is not in the list it means you need to install it. On Debian the package is called “pidgin-libnotify”, other distros should have a package with a similar name.
• XChat-GNOME: Click on the “Edit” menu and then “Preferences”. In the “Scripts and Plugins” tab make sure that “On-screen display” is enabled.
• XChat: Click on the “Settings” menu and then “Preferences”. In the “Alerts” tab make sure that “Show tray baloons” is enabled for both “Private Message” and “Highlighted Message”. If the notifications pile up in the bottom right corner of your screen and clicking on them does nothing, it means that XChat is using notify-send because it cannot find libnotify. I don’t know how to fix this issue on different distros, but I found a Red Hat bug explaining the problem.

Notifications coming from Empathy and XChat-GNOME

Is there any other common application that you would like to be handled by my plugin? The only prerequisite is that they somehow use standard notification bubbles (and this means I cannot implement it for Skype).

If you are looking for the source code, it’s in this git repository.

Of the Wayland demo clients in the Weston repository, simple-shm is the simplest. All the related code is in that one file, and it interfaces directly with libwayland. It does not use GL or EGL, so it can be ran on systems where the EGL stack does not support the Wayland platform nor extensions. However, what it renders, is surprising:

The original simple-shm client on a Weston desktop.

The square with apparently garbage texture is the original simple-shm. To any graphics developer, who does not know any better, that immediately looks like something is wrong with the image stride somewhere in the graphics stack. That really is what it was supposed to look like, not a bug.

I decided to propose a different rendering, that would not look so much like a bug, and had some real diagnostic value.

The proposed appearance of simple-shm, the way it is supposed to look like.

The new appearance has some vertical bars moving from left to right, some horizontal bars moving upwards, and some circles that shrink into the center. With these, you can actually see if there is a stride bug somewhere, or non-uniform scaling. There is one more diagnostic feature.

This is how the proposed simple-shm looks like when the X-channel is mistaken as alpha.

Simple-shm uses XRGB buffers. If the compositor does not properly ignore the X-channel, and uses it as alpha, you will see a cross over the image. Depending on whether the compositor repaints what is below simple-shm or not, the cross will either saturate to white or show the background through. It is best to have a bright background picture to clearly see it.

I do hope no-one gets hypnotized by the animation. ;-)

Recently, I’ve been working on making GDBus’ unit test helpers as public API on libgio (see bug #672985). Thanks to the help from David Zeuthen, it landed in gio master as GTestDBus object.

The basic idea is simple: g_test_dbus_up() starts a dbus-daemon and sets DBUS_SESSION_BUS_ADDRESS env variable. That means that your tests will then be using that private session bus instead of messing with user’s. When the unit test is done, call g_test_dbus_down() which will kill the dbus-daemon. Of course in the case you unit test fails and crash, it still make sure the dbus-daemon will be cleaned.

And finally, thanks to Alexander Larsson, it even works on win32.

Enjoy

I'm currently dealing with a very obfuscated and over-engineered codebase, with layers upon layers upon layers. There is always a silver linning though and I finally got around to learning how to use etags in emacs. I can't believe I waited this long to learn this feature, specially since it is so easy.

etags lets you quickly locate a definition by its name anywhere in your code base.

1. First, you need to tag the code. Go to the base directory and run

$ etags `find . -name "*.c" -o -name "*.h"`

This will generate a 'TAGS' file.

2. Let emacs know about the tag file

M-x visit-tag-table [location of the TAGS file]

3. With the cursor on a function call do the following

M-. (which is ALT-.)

This will take you to the function definition anywhere in the entire directory structure

4. Now if you want to go back

M-* (which is ALT-SHIFT-*)


Cool, isn't it? It gets better!
That's not all you can do with the TAGS file. Imagine that you are dealing with very long function names or can't quite remember the exact name. No problem. Type the first few characters of the name, then press M-tab. Either the full function name will appear, or a window will pop up displaying a list of possible completions.

If you like this checkout smart-tab. It allows you to use the tab key to indent and tab complete function/variable names.

** Alternatively, you can use 'make tags' to generate the 'TAGS' file.

Yesterday Google released the accepted students for this year’s Google Summer of Code and BlueZ will be participating with 4 students:

Project: Bluetooth Replayer
Student: Anton Weber
Mentor: Anderson Lizardo

Project: OBEX Filesystem In Userspace
Student: Michał Poczwardowski
Mentor: Vinicius Gomes

Project: Implement AVRCP 1.3 Controller Role
Student: Rafael Fonseca
Mentor: Luiz Augusto von Dentz

Project: Visualization of Bluetooth traffic
Student: Thiago da Silva Arruda
Mentor: Gustavo Padovan

It is now community bonding time, where students get know their mentors and the community. We wish a great summer to all students.  :-)

 

So there are these really cool debugging macros for GLib/GObject that do things like let you iterate GLists and pretty print GObjects and GHashTables and stuff that should nowadays be available in most distros.

Unfortunately when you build your own GLib to develop against, it all breaks.

It turns out, gdb locates when to load these things by looking in $prefix/share/gdb/auto-load/ and matching the sonames, so if you have libraries with a different soname (cause they’re new versions), or in a different prefix, it just doesn’t work.

Damien Lespiau has a workaround for this that adds a command to load them from a path you can control with sys.path; which works. I looked a little for a generic solution to feed the autoloader from my GLib build prefix, but I haven’t found one yet.

Having now looked at this. I’m also excited about possibilities for combining this with GObject-Introspection to potentially do some useful things. I don’t know what the caveats are here yet, what’s safe to call and what’s not.

When working with a new git project, I like to publish my patches in git branches on my public git server. I usually use the collabora git server, but some people also have account on freedesktop, etc. But it’s a bit long just to publish a branch:

1. locally: git clone ssh://git.gnome.org/git/empathy
2. locally: ssh git.collabora.co.uk
3. collabora: cd public_html/git && git init --bare git://git.gnome.org/empathy
4. locally: git remote add xclaesse git+ssh://git.collabora.co.uk/git/user/xclaesse/empathy

Note how GNOME urls are different in 1) and 3), not only the ssh:// VS git:// but also the extra /git/ and it’s different with freedesktop.

So my first step to simplify this is to define insteadOf URLs in ~/.gitconfig both locally and on server:

locally:

[url "ssh://git.gnome.org/git/"]
    insteadof = gnome:
[url "git+ssh://git.collabora.co.uk/git/user/xclaesse/"]
    insteadof = collabora:

on server:

[url "git://git.gnome.org/"]
    insteadof = gnome:

Now the steps are:

1. locally: git clone gnome:empathy
2. locally: ssh git.collabora.co.uk
3. collabora: cd public_html/git && git init --bare gnome:empathy
4. locally: git remote add xclaesse collabora:empathy

Still I’m lazy so I don’t like sshing the server manually, so the final step is to add this git alias in your local ~/.gitconfig:

[alias]
    fork = !git config --get remote.origin.url | xargs -n 1 ssh git.collabora.co.uk \"cd ~/public_html/git && git init --bare\"

That will create a public repository for the project you’re currently in, just by typing “git fork”! Steps are now:

1. locally: git clone gnome:empathy
2. locally: git fork
3. locally: git remote add xclaesse collabora:empathy

After more than 3 years working at ProFUSION embedded systems I decided it was time to a move: Today is my first day (of many) at Collabora Ltd. :-)

I would like to take the opportunity to thank people at ProFUSION for the time I’ve working there. Those were good times.

And for the Collaborans: I hope we will rock a lot together. I’ll keep updating this blog with posts about my work at Collabora.

See you around. ;-)

I like the *process*. I like writing software. I like trying to make things work better. In many ways, the end result is unimportant – it’s really just the excuse for the whole experience. It’s why I started Linux to begin with – sure, I kind of needed an OS, but I needed a *project* to work on more than I needed the OS.

In fact, to get a bit “meta” on this issue, what’s even more interesting than improving a piece of software, is to improve the *way* we write and improve software. Changing the process of making software has sometimes been some of the most painful parts of software development (because we so easily get used to certain models), but that has also often been the most rewarding parts. It is, after all, why “git” came to be, for example. And I think open source in general is obviously just another “process model” change that I think is very successful. [...]

It’s simply not the end that matters at all. It’s the means – the journey. The end result is almost meaningless. If you do things the right way, the end result *will* be fine too, but the real enjoyment is in the doing, not in the result.

Linus Torvalds

(source interview with TechCrunch)

A few months ago I wrote a gnome-shell extension that shows how many conversations with unread messages you have, so that I could stop missing incoming messages.
I updated the extension so it now works better and it can also show what the incoming notifications are when you press the icon. You can get the new version (and install it with just two clicks) from extensions.gnome.org. If you previously installed the extension from git and you don’t have an update button on that page it could mean you need to first manually remove ~/.local/share/gnome-shell/extensions/message-notifier@shell-extensions.barisione.org/ and reload the shell (ALT-F2 and then type “r”).

Note that the extension shows the number of conversations with new messages and not the number of messages; I don’t like seeing “2” up there if somebody just wrote me “hi” and then “how are you?”.

There is still a major problem with the extension. I wanted to be able to also see if somebody pinged me on IRC (I’m a XChat-GNOME user) so I don’t limit the count to active chat conversations, but I consider all the active notifications. I find this very useful to avoid missing something, but it means that the red icon will also appear every time banshee or rhythmbox change song. Suggestions on how to solve this?

Changing completely topic, I recently moved to a new home and, having a nice new kitchen (with dishwasher), I started cooking a lot again. I decided to start a new cooking blog called gnocchialpesto.co.uk to keep track of my recipes and share them with others. If you like food, in particular Italian one, take a look at it .

Apparently I’ve had a github account for ages, and never used it. Recently I’ve been using github a for some work I’ve been doing with Intel at Collabora.

Anyway, I thought it might be neat to move some of my random personal projects and misc that were stored on git.collabora.co.uk to github.

Completely unscientific benchmark, just to get you salivating for GStreamer 1.0



X = time, Y = CPU%
gst 0.10 and 0.11 from git, vlc 1.1.12, vlc 2.0.1-0-gf432547, mplayer SVN-r33713-4.6.1
test file: video: H.264 - audio: MPEG-4 AAC

(benchmark created by Wim Taymans)

Xavier suggested I blog my Git aliases.

[alias]
	ci = commit -v
	prune-all = !git remote | xargs -n 1 git remote prune
	record = !git add -p && git ci
	amend-record = !git add -p && git ci --amend
	stoat = !toilet -f future STOATS
	update-master = !git checkout master && git pull -r
	lol = log --graph --decorate --pretty=oneline --abbrev-commit
	lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

Mostly¹ self-explanatory.

git ci

Shorter than git commit, and -v shows you what you’re about to commit.

git prune-all

From the Git wiki.

git record; git amend-record

I started using these as a Darcs refugee, but they’re also a good way to avoid doing git add -p && git commit -a through overly-active muscle memory. I could probably simplify them to use git commit -p.

git lol; git lola

…come from Conrad Parker.

What’re your favourites?

1. No, I don’t remember why I added git stoat either.

Finally, the deed is done.

https://projects.kde.org/projects/kde/kdemultimedia

KDE Multimedia has finished migrating from subversion to git.

I’d like to thank everyone on the KDE sysadmin and multimedia teams for helping me sort things out and get it finished.

ninja edit: The sysadmins changed the link minutes after I posted so the i18n teams wouldn’t have to tweak their scripts.