On the most basic level there is the classical chaining of Unix commands connected via pipes. This works when you are streaming raw data. That’s not what I am interested in, I am considering the case where the parent process uses the child as some helper and the parent sends the child a stream of commands.

There are two common approaches these days.

1. Invent an ad-hoc protocol and the parent communicates to the child via that. This will be super effective (if you are clever about it), but require some work on your behalf.
2. Totally decouple parent and child and use the DBus session bus between the two.

On the free desktop there seems to be a trend towards 2. Probably because it is just some damn convenient!

The DBus approach comes with quite some attachments though.

• You now have a public API on the bus (you may tell people that it is private, but that is not always gonna be respected)
• You’re adding round trips to the bus daemon
• Other processes can eavesdrop
• You may really want to send quite a lot of commands

As it happens, round trips and bus spamming is very detrimental to the entire desktop (it causes priority inversion and general lagginess as was described in the document located here, which unfortunately has gone 404(??)). So you definitely want to do that carefully.

Enter Teh Hack. It solves all of the listed problems, and gives you the nice API of GDBus. The idea is to talk DBus, but over a pipe, not a socket. Let’s call the idea DPipe to have a word for it. You might be surprised to hear that this Just Works ™. At least when using the awesome GDBus implementation. I’ve pasted a complete example, in Vala, below.

It’s a bit hackish, as it is, but the idea is simple enough. Create a GIOStream with the two pipe ends. Create a new GDBusConnection with this GIOStream. The parent must be careful to only write to the connection and the child must be careful to only read. But I can trust you on that, right?

/* 
 * Hack: Using the stdin/stdout pipes for DBusConnections
 * Compile with: valac --pkg gio-2.0 --pkg gio-unix-2.0 dpipe.vala
 * Run with: ./dpipe | ./dpipe client
 */
 
namespace DPipe {
 
  /* We need a custom IOStream subclass, as IOStream is abstract */
  class Stream : IOStream {
 
    private InputStream _in;
    private OutputStream _out;
 
    public override InputStream input_stream { get { return _in; } }
    public override OutputStream output_stream { get { return _out; } }
 
    public Stream (InputStream input, OutputStream output)
    {
      _in = input;
      _out = output;
    }
  }
 
  int main (string[] args)
  {
    Stream stream = new Stream (new UnixInputStream (stdin.fileno(), false),
                                new UnixOutputStream (stdout.fileno(), false));
 
    DBusConnection conn = new DBusConnection.sync (stream,
                                                   "fixme",
                                                   DBusConnectionFlags.NONE,
                                                   null,
                                                   null);
 
    if (args.length > 1 && args[1] == "client")
    {
      /* Beware: The filter handler runs in the GDBus worker thread */
      conn.add_filter ( (conn, msg, incoming) => {
        print ("Got message on %s: %s\n", msg.get_interface(), msg.get_body().print(false));
        return msg;
      });
    }
    else
    {
      conn.emit_signal ("target.name",
                        "/target/path",
                        "target.iface",
                        "SignalName",
                        new Variant ("(s)", "Hello dpipe"));
    }
 
    MainLoop mainloop = new MainLoop ();
    Timeout.add_seconds (1, () => { mainloop.quit (); return false; });
 
    mainloop.run ();
    return 0;
  }
}

But please don’t got hating on me if this blows up on you. I really haven’t played with it a whole lot.

Now, as some have picked up, the Unity Lenses API has changed slightly in Unity-5.0 (the version that’ll be in Ubuntu 12.04). First of all; sorry! As I’ll outline why we did this you’ll hopefully learn to appreciate it. Flames and pitchforks can go in my general direction if not. And if you still have hate to spare after that you can direct it at Michal Before we start, do note that the Unity-5.0 API overview on developer.ubuntu.com is already updated, and Michal is updating the wiki documentation.

I’ll take this on in the form of a case study; updating my unity-lens-bliss. This is a Python lens, which makes for a good example – identical changes apply to lenses written in Vala or C. Let’s roll.

Porting unity-lens-bliss to Unity-5.0

We introduced a new signal “search-changed” on the Unity.Scope class. The old property notification (on “notify::active-search” and “notify::active-global-search”) is still not available anymore, as the properties has been removed. The reason for the new signal was that the property notification scheme was racy in some subtle ways that would require some tricky GObject magic in the scopes to work correctly in all circumstances. The race manifested itself in lenses that dispatched the property change notification to an async handler of some sort. If the scope received another search while the async handler was still running we’d have re-entrancy issues in the async handler. This was the reason why you might have seen some mysterious calls to self.freeze_notify() and self.thaw_notify(). It seemed that no one really understood this, and I think we can all agree that having to know the intricacies of GObject property notifications is not a nice requirement for an API that should be simple.

For unity-lens-bliss, what was before:

self.connect ("notify::active-search", self._on_search_changed)
self.connect ("notify::active-global-search", self._on_global_search_changed)

Should now become:

self.connect ("search-changed", self._on_search_changed)

The callback  _on_search_changed() changes signature from:

def _on_search_changed (self, scope, param_spec):

to

def _on_search_changed (self, scope, search, search_type, cancellable):

The search parameter is a LensSearch instance. The LensSearch class has grown some new public properties. Of particular interest is the “results-model” property. This property will hold the correct model depending on whether it is a global- or in-scope search. You can figure out what kind of search this is by looking at the search_type parameter which is an enumeration Unity.SearchType with values Unity.SearchType.GLOBAL and Unity.SearchType.DEFAULT for global- and in-scope searches respectively.

So the implementation of the _on_search_changed() callback changes from:

def _on_search_changed (self, scope, search, search_type, cancellable):
	search = self.get_search_string()
	results = scope.props.results_model
 
	print "Search changed to: '%s'" % search
 
	self._update_results_model (search, results)
	self.search_finished()

to

def _on_search_changed (self, scope, search, search_type, cancellable):
	search_string = search.props.search_string
	results = search.props.results_model
 
	print "Search changed to: '%s'" % search_string
 
	self._update_results_model (search_string, results)
	search.emit("finished")

And this is all there is to it! Bliss will work fine in Unity-5.0 with these changes.

We haven’t yet mentioned the new parameter cancellable. Unsurprisingly (hopefully ) this is a Gio.Cancellable instance. If you’re writing a fully synchronous lens (like bliss is) it wont be of interest to you, but if you’re dispatching to async methods from your “search-changed” handler (like fx. both unity-lens-files and unity-lens-applications does) then read the next section carefully.

Concurrency and Cancellation

Before we get too deep into this, let’s make it clear what I mean by asynchronous. A method being async means that GLib will spin the mainloop while waiting for the method to return. This means that your app/daemon will continue to handle events (in particular requests from Unity to update the search) while your methods are running. Why would one want to use async methods if it is so complicated? Good question. If you’re just writing a simple scope or lens then chances are that it may not be worth it. But if you go beyond “simple” then it may matter.

Let’s imagine a slightly more complex scope. Maybe something that puts webapps inside the applications lens. The listing is done by first asynchronously querying a web service to list the apps and then asynchronously querying Zeitgeist to sort by popularity. If we didn’t do the web- and Zeitgeist queries asynchronously then the scope would block all requests while any queries were running. This would mean slower responses if the user changes the query under you (which is very likely when we’re talking live searching here), and also you’d run the chance of showing “outdated” results and doing work that you’ll discard immediately anyway. What you want is to be told in the middle of everything that “hey, there’s a new query; stop what you’re doing and do this in stead!”.

An alternative case where’d you want async searching is if you wrote a scope that was living inside an application. There’s really no reason why this wouldn’t work. And it circumvents some of the intricacies of sharing a datastore between a scope daemon and an app. Anyways, back to the example with the web apps. In simplified form it would look something like this:

def _on_search_changed (self, scope, search, search_type, cancellable):
	# Dispatch an async call with callback _on_web_apps_received()
	self._query_web_service_async (search, self._on_web_apps_received)
 
def _on_web_apps_received (self, search, list_of_webapps):
	# Web apps listed by remote server.
	# Now sort them async with zeitgeist, with callback _on_webapps_sorted_received()
	self._sort_webaps_with_zeitgeist_async (list_of_webapps, search, self._on_webapps_sorted_received)
 
def _on_webapps_sorted_received (self, search, sorted_list_of_webapps):
	# We now have the web apps sorted by popularity,
	# add them to the results model
 
	results_model = search.props.results_model
	results_model.clear ()
 
	for app in sorted_list_of_webapps:
		results_model.append(...)
 
	search.finished ()

If you did something like this in the Unity-4.0 API then have to deal with all the re-entrancy, cancellation, and concurrent search handling yourself. Probably by elaborate application of freeze/thaw_notify() and Gio.Cancellables. Tricky stuff. In Unity-5.0 this is a breeze! Contrary to the old way with “notify::active-search” libunity goes out of its way to make the “search-changed” signal nice to use for scope authors (and no, it wouldn’t be technically possible to do the same with the old property notification system).

Firstly, libunity wont call you again before you’ve called search.finished(). So we’re re-entrancy safe in the example already. What’s more – libunity will cancel the cancellable parameter when you get a new query. So sprinkling some if cancellable.is_cancelled(): return lines around will make sure that you don’t do work in vain. We could fx. insert one  right after we receive the results from the web service. Note that you don’t have to call search.finished() if you have been cancelled (libunity will ignore it if you do):

def _on_search_changed (self, scope, search, search_type, cancellable):
	self._query_web_service_async (search, cancellable, self._on_web_apps_received)
 
def _on_web_apps_received (self, search, cancellable, list_of_webapps):
	# NOTE: The new parameter        ^^^^^^^^^^^
	if (cancellable.is_cancelled()): return
	self._sort_webaps_with_zeitgeist_async (list_of_webapps, search, cancellable, self._on_webapps_sorted_received)
 
def _on_webapps_sorted_received (self, search, cancellable, sorted_list_of_webapps):
	# NOTE: The new parameter              ^^^^^^^^^^^
	if (cancellable.is_cancelled()): return
	...

Filters

Bliss doesn’t use filters, so I didn’t touch on that yet. If your scope is using filters, the correct thing is in 99.99% of all scopes to connect the “filters-changed” signal to calling self.queue_search_changed(Unity.SearchType.DEFAULT). In Python:

def __init__ (self):
	...
	self.connect ("filters-changed", self._on_filters_changed)
 
def _on_filters_changed (self, scope):
	self.queue_search_changed(Unity.SearchType.DEFAULT)

Personally I’d probably do it with lambdas:

	...
	self.connect ("filters-changed",
	              lambda scope: self.queue_search_changed(Unity.SearchType.DEFAULT)

Out of Band Result Changes

Many scopes feature result sets that can change through external means. Fx. if you  are listing the contents of a directory, listing browser bookmarks, listing recent stuff from Zeitgeist, etc. All can change when the user is doing something else than searching the lenses. When the result set should be updated, disregarding whether the search string has changed, you can call self.invalidate_search().

Search String Change Checking

In the previous paragraph I wrote “disregarding whether the search string has changed”. But when has the search string changed? Does appending a white space change the search string? Most lenses strips the search string from white spaces anyway; so in essence the strings “xyz” and “xyz    “ are identical, seen from the scope. We don’t want to fire off a new search for these kinds of changes. Going further down this road – is “XYZ” and “xYz” the same as well? For most scopes, they will be. The problem is that this is highly dependent on the particular scope.

Doing change checking on search strings was a recurring chunk of similar code in all the default Unity lenses. In order to make this easier for our selves and everyone we baked it into libunity by means of the “generate-search-key” signal on the Unity.Scope class. This is a particular kind of signal that has a return value. The signal takes a Unity.LensSearch as input and returns a “normalized” version of the search string. This could typically be lower casing and chugging off white space at the ends. In code:

def __init__ (self):
	...
	self.connect ("generate-search-key", self._generate_search_key)
 
def _generate_search_key (self, scope, search):
	return search.props.search_string.lower().strip()

Cancellation and Transactions

Considering again the example with async searches and cancellation. One could easily imagine a scenario where you had a bunch of async methods, some of which added rows to the results model and then going on to dispatch more async searches before calling search.finished(). If we got cancelled in the middle of all this, the results model would be left in a dirty state with only half the results of the search. Enter Dee.Transaction.

Dee.Transaction is new class in Dee that implements the Dee.Model interface. You create a new Transaction instance, txn, from your results model, then go on clearing and adding rows to the txn model as you go through your chain of async calls. The real results model will not be updated before you call txn.commit(). So if you’re cancelled somewhere in the middle you just let txn go out of scope (or unref it if you’re writing in C) and it’ll vanish like the Cheshire cat. If you make it all the way to the end you call txn.commit() right before you call search.finished(). So with an example:

def _on_search_changed (self, scope, search, search_type, cancellable):
	txn = Dee.Transaction.new (search.props.results_model)
	self._query_web_service1_async (search, txn, cancellable, self._on_web_apps1_received)
 
def _on_web_apps1_received (self, search, txn, cancellable, list_of_webapps):
	# First set of results retrieved, add them to the transaction
	# and then fetch some more results from another web service
	if cancellable.is_cancelled(): return
 
	txn.clear ()
 
	for app in list_of_webapps:
		txn.append(...)
 
	self._query_web_service2_async (search, txn, cancellable, self._on_web_apps2_received)
 
def _on_web_apps2_received (self, search, txn, cancellable, list_of_webapps):
	# Second batch of results
	if cancellable.is_cancelled(): return
 
	for app in list_of_webapps:
		txn.append(...)
 
	txn.commit ()
	search.finished ()

Fin!

Wow, you’ve made it to the end of this blog post! You surely are an impressively patient person

Please feel free to ask questions or post corrections in the comments. Or catch me, kamstrup, or Michal, mhr3, on #ayatana on FreeNode if you’re into IRC.

Now as a bonus for your patience you’ll get… A FREE picture of Me Looking At A Webcam!

Me being the maintainer of the applications lens in Unity you might wonder why I am now blogging about an alternative apps lens – let alone why I actually wrote the alternative myself!

I am personally quite happy about the current default apps lens in Unity. It doesn’t try to be too smart, but aims more for the simple and intuitive. That’s why we only do prefix matching on the words in the application, eg  if the user types “term” it matches th word “Terminal”, but not “XTerm”. We also want the matching to be consistent with that of the results coming from the Ubuntu Software Center – which also works with prefix matching.

Not all users find prefix matching to be the best thing since sliced bread. I like it, but astonishingly the whole world doesn’t think like me!? Nonetheless I can respect that

Some users wants to see substring matching which means that “term” matches both “Terminal” and “XTerm”. More progressive users wants a more powerful approach that we can call subpattern matching where the letters in the input string must occur in the same order in the string we test against, eg. “term” matches both “Terminal”, “XTerm” and “Television Remote”. This can also be thought of as some sort of “acronym matching”.

Matching algorithms aside some users simply hate to search for their apps and doesn’t like to go digging in the filters we have on the right (the filters are also hidden by default which makes them not so easily discoverable). They want to browse their good olde hierarchical menus.

… some users abhor the Most Used and Downloadable apps categories of the deafults lens – and some users probably want something completely different!

Had I not been an old fart I would probably gladly had added tonnes of options to the unity-lens-applications codebase trying to make everyone happy. But I am an old fart I want a simple and tight codebase and I don’t want tonnes of options because that makes the code harder to maintain. More tricky maintenance means that the ones that are happy with the defaults will suffer.

Enter the power of Unity! You see; Unity is not only a shell in the user-facing kinda way. It is also a shell in the programmable kind of way The default lenses are not hard coded, you can replace them. So you can replace the apps lens as well if you want.

I’ve aired the idea of writing an alternative apps lens numerous times to the ones requesting changes, but none ever appeared that I know of. So I was thinking that I could maybe kick start that effort if I provide a solid starting point. Hence I whipped up Bliss, https://launchpad.net/unity-lens-bliss.

Bliss is a very simple replacement for the apps lens. It does basic searching with substring matching and it allows you to browse your apps by category. It also contains a good collection of bugs, but I’ve been dogfooding it here for a while now and it’s nothing unbearable

Considering the new focus on power users for the Precise cycle I thought/hoped that I could inspire someone to grab the code and write a production ready app launcher specifically tailored for power users. I made the code so that it should be easy to hack on and extend, so let’s see where it ends up…

Caveat emptor: Bliss is by no means official or anything. It is a quick hack to showcase how you can go about this, mostly intended for developers who want to do their own thing. That is also why you wont find a PPA for it (not from me at least ).

Intruding Bliss, an Alternative Apps Lens for Unity from Mikkel Kamstrup Erlandsen on Vimeo.

So branch it, hack it, break, it, fork it. Knock yourselves out!

(I know of at least two obvious bugs: b1) the back arrow sometimes doesn’t appear as the first item, b2) the More Apps shortcut on the dash home screen breaks when you remove unity-lens-applications)

Apple is a big contributor to open source and has clearly inspired a lot of things in the open source world, so it wouldn’t be an overstatement to say that I have daily exposure through my work. With my view from the code trenches I’ve seen the entire tech world being paced forward by Steve’s unwaivering focus. I’ve always been highly skeptical of Apple’s way to do business, but I guess I’ve grown a subconscious acknowledgement how important Steve has been to the computing world. Knowing that he was fighting cancer I think this promoted respect to inspiration. Adding in the massive online emotional hype this must explain why I got so bummed out.

My sadness turned into grumpiness later today when I learned about Mark Pilgrim’s recent departure from the online world (on 4/10 to be exact – HTTP code 410, GONE).  I have all respect for him wanting to leave the digital world, but the way he did it is just not cool. Thousands of people looked to him as a role model (including me) or relied on his abundant and generous online materials to do their jobs.

Deliberately pulling the plug without warning is just unfair. You can go out like a gentleman or you can go out like an asshole.

When I wake up tomorrow I am gonna wake up to a new world, without Jobs, without Pilgrim. Meh.

A few years back it was all the rave to get rid of the “login splash” – for newcomers: GNOME used to have splash screen displayed while it was loading your desktop. The mantra in the community was “Let’s login so fast that we don’t even need a splash!”. Lots of people did awesome hard work and we got to a point where we could reasonably remove that splash screen. That’s all well and good – but recent developments in the device industry has shown people that it’s not really the boot/login time that kills you, it’s the app startup time. And I confess; I totally jumped on that band wagon.

Sure – it’s annoying as heck that my Android phone takes ages (bloody ages!) to boot up. But my nerves are instantly soothed by the responsive system that comes alive. And this is something I’ve heard over and over and over again. From Apple fangirls to Android fanboys – users really dig the fast loading apps. Unrelated non-tech people have highlighted to me that the primary feature they loved on their tablet computer of choice was the fast app launching.

So my rhetorical question: “Startup time, why do we have it anyway?”. Maybe this is really a call to rally. Let’s make our Gnome apps start instantaneously!

But let me get slightly more technical. If you’ve ever set up a semi complex prototype of a Gtk+ app, some C stub code and a Glade project, you’d probably have seen that it starts up almost instantly. So why doesn’t it do that anymore when you put actual real world code in there? This is of course where it all starts to get tricky. Common things that make startup slow:

• Anything you load of disk takes time (and don’t even think about writing). More files to load is bad, badder, baddest. Also if you do it async, less apparent but still. On a related note: For some reason heavy IO of any kind messes up graphics performance under Linux. So – just really minimize that IO on startup.
• There’s a tradition to set everything up before you show the window. This avoids that your layouts will be jumping all over the screen if you show your window immediately and start populating it with data. So you need a clever way to get the widget sizes just about right before really knowing what you’ll end up putting in there. This needs clever thinking by app authors, but maybe also some clever help from toolkit writers?
• Complex data model? Maybe you have a simple on disk format that is quick to load, maybe even mmap()able, but requires lots of secondary parsing? Try to be clever and only parse what you need to show something and delay the rest until the user is distracted.
• Using spinners when waiting for data. If the window and empty widgets are there in a snap the user wont really notice the 1-2s spinny there. Otoh if you add 1-2s on startup time they’ll have that hard-to-place sluggish feeling of the system.

If we want instant app launching to be something we can do in Gnome, then it requires a big concerted effort, but definitely not insurmountable. We’d need to play around with a few techniques, someone documenting the good ones, identifying patterns and anti patterns and making it part of our documentation. Maybe adding in some support from the plumbing layers and toolkit and we could really make this sing.

Jason proposes a 250ms startup budget. A little playing around shows me that this is very ambitious with our current stack and a semi complex app (our desktop apps tend to be more complex than mobile apps, so mobile apps have the obvious advantage there). Before reading Jason’s proposition my idea was 500ms, but maybe we should really aim for the 250ms?

What’s your take on this?

(as a closing remark let me add that I deliberately didn’t put my SSD in my new laptop because I want to feel the pain. Feel the pain so that we can eradicate it also for those without SSD)

I had so many grand plans for the leave, but pretty much the only one of them that I didn’t abandon was that of taking care of the baby and the household. I really thought I had it all planned and ready to roll as this was the third kid and I knew the drill. Not so much

Most of the ditched plans were related to coding somehow, but I ended up spending next to no time in front of the screen (compared to what I normally do! not compared to what normal, sane, people do). Looking back on the 4 months there was a tonne of stuff that I did get to do. Fx. exploring the finer details of bread making, brew some beer, brew some apple wine (still waiting on that one), work on our house in Ålbæk, learned about the Japanese cuisine, refreshed my old math curriculum from uni, and started to read up on the maths and physics behind superstring theory (mostly the math part)…

… enough with the link dropping, who am I trying to fool – it was really mostly about diapers, laundry, dish washing, and sleepless nights

Hopefully unsurprisingly – the Python integration is all done with PyGI, the Python bindings for GObject Introspection. I must admit that it was a slight challenge getting everything working smoothly, but we’re there now. I want to give mad props to the pygobject- and the GObject Introspection teams. Without their enduring help we wouldn’t have got to this point. So thanks guys, you rock!

So lets get down to business. How does this work, what does it look like?

Setting up a Development Environment

First you need to make sure you have the required development packages installed (you can just click the links to install them if you want):

sudo apt-get install gir1.2-unity-3.0 gir1.2-dee-0.5 gir1.2-dbusmenu-glib-0.4

Now, unfortunately not everything you need is packaged just yet. Namely you may need to install the so called Python overrides for the Dee library. Check if you have this file on your system:

/usr/lib/pymodules/python2.7/gi/overrides/Dee.py

If you don’t have that file it means you’re in in the vicinity of the writing of this blog post, in the time dimension; and thus must install it manually. Here’s how. Download Dee.py and copy it to the right location for PyGI to pick it up:

sudo cp Dee.py /usr/lib/pymodules/python2.7/gi/overrides/

With that in place we’re ready to hack.

Writing a Place in Python

The easiest way to start is to check out lp:~unity-team/unity-place-sample/unity-place-python:

bzr branch lp:~unity-team/unity-place-sample/unity-place-python

And then closely follow the README. If you read through it while having the Unity Places spec and IRC log from the devsession at hand you should have a chance of grokking what’s going on. If you have any problems or questions don’t hesitate to ping me on IRC on the #ayatana channel on FreeNode.

I should also add that we’re working on getting some Python API docs for Dee, Dbusmenu, and libunity out. Watch this space!

My own pet peeve, the Storage Awareness branch is inches from landing. It will allow the following kinds of new features:

• Exclude files from a query that are not available to the user right now. Fx, because they are on a USB stick or require internet access when you don’t have any, or
• imagine a journal-kinda-view where you can still see files you accessed that where on drives that are no longer attached. When you click them a dialog pops up “Please insert the drive ’2GB SanDisk’ in order to open the file ‘foo.txt’”.
• When you plug in a USB drive you are presented with your most recent activity related to that drive
• List which storage devices you’ve used an when

Michal was just all over the place doing integration work on everything between glib, libzeitgeist, gedit, totem, what not. From where I sit this guy just had an amazingly productive week!

Seif worked on the “grid plugin” for GEdit which is originally Michal’s idea and something we where all pretty hyped about. Really something that I feel could make a huge difference in the user experience of many Gnome apps.

Morten did a lot of work to get Zeitgeist ready for some deep Telepathy integration, this required a lot of hard thinking and a lot of discussion (with Seif and yours truly, but don’t worry we’re all still friends ). Getting it “just right” was not trivial, but I think we got to a point where we have a very good battle plan on how to get all the way to working code.

Siegfried worked on Gnome Shell integration and I think we should start seeing the fruits of that very soon now – and Federico joined remotely.

We also got some media coverage which, as often goes, was not entirely accurate, so Manish took the time to straighten out the facts

Once again, big thanks to our sponsors – the opportunity they have given has made a huge difference!

We spend the first 2 hours figuring out what items to focus on and who does what and Seif compiled it into a list of assigments on the wiki.

Seif, Morten, and I talked about what pieces we needed to fit together to make the Zeitgeist and Telepathy integration work perfectly. Got some nice and simple work items nailed down that’ll take us a long way.

While we did that Michal updated the zeitgeist-datahub to listen for the new DBus signal emitted by GDesktopAppInfo when they are launched. He also worked with Colin Walters on getting a nifty little patch that adds some extra info to the DBus signal that will make Zeitgeist even more clever when logging your app usage patterns. Uh… And Michal is brewing up something awesome for you as well, but I shall not steal his thunder

My personal little project was to update and make my “Storage Awareness” branch from a while back ready to merge to trunk. There are some kinks to iron out before it’s ready, but I’m most thrilled about the prospect of getting this done.

Oh! And there is a #zeitgeisthackfest hashtag if you wanna bigbrother us on Twitter

Prepping up for the Zeitgeist hackfest which is kicking off tomorrow in Aarhus, Denmark. You’ve probably not heard a lot about this event before this late moment – that’s because it has all happened a bit fast. As we where internally discussing the possibilities of a hackfest a bit back, it quickly became evident that we needed it hold it Very Soon Now (TM) if we wanted all the core maintainers to have a chance of showing up.

I was wincing a bit because we recently expanded our family (can you believe I have three kids now..? I’m not sure I can) and I wasn’t very keen on traveling more than I already do with my work. Seif, being the man of action that he is, didn’t let that put him off an arranged that we could hold the hackfest conveniently close to my home. Not only that, but he pretty much did all of the necessary arrangements for getting a cool venue, accommodation, and not least – getting some sponsors to help us out. Seif – this one is to you – you rock man!

The sponsors are the GNOME Foundation and Collabora, and the venue will be the CS Department at Aarhus University, in the Incuba Science Park. All have been incredibly helpful despite our short notice. Thanks to everyone involved!

I’m gonna have to hold the suspension a bit about what we intend to do with this precious opportunity we’ve been given. I’m just too tired right now – but my plan is to have a short daily log posted on my blog each day. So by the end of this week you should all hopefully have an idea Stay tuned.