Just a short post, as I'm by now fashionably late for this.

I attended MeeGo Conference in San Francisco in May, my greatest thanks to my excellent employer, Collabora Ltd for sponsoring my trip. It was a pretty intense week for a lot of reasons, one of which being that the week before my visit, I was asked to demonstrate some software I have been working on, a sort of mesh synchronised object store.

I showed off a simple contacts application synchronising contacts across three devices, but my real plans for that are a lot more - but that is content for another post, perhaps, another day. I think the show went pretty well, certainly, the reception of some parts of the keynote was a bit mixed.

It was also the first time I have visited the US before, and it was certainly a different experience to practically anywhere I have been before. San Francisco was an interesting place in particular to visit, with extreme contrast (people living on the streets with obvious mental issues, while there are villas in the background etc.) and typical cultural differences, some of which I found quite strange, like mandatory tipping. All in all, I think I'd visit again, though.

The conference itself was quite excellent, lots of interesting talks going on, and as usual, meeting all the familiar faces - and making new friends - was fantastic. I only wish I had been less frantically busy and jetlagged (or tired after being busy) to make more of the experiences. By the time I had recovered from everything, the conference was almost over. Though thankfully, I spent an extra two days wandering the streets of the city seeing some sights.

I'm not someone who likes to travel. But I honestly don't seem to be able to avoid it, especially these days.

I moved from Australia when I was 19, to move to the United Kingdom, both because of my significant other and because I had been offered work. Thanks to her, I travel to Norway an awful lot, too, seeing as that's where she's from. We're planning on moving there this summer, too.

In addition to that, I occasionally travel places for work (I've been to Finland once this year), and various conferences, which is the 'meat' of this post. I'm attending MeeGo Conference in two weeks time, in San Francisco, and I've just booked my tickets for the Qt Contributors summit in Berlin in June.

All in all, we're only in the first half of the year, and I've already visited (or planned to visit):

• Norway
• United Kingdom
• Amsterdam (as a stopover)
• Germany
• United States
• Finland

So, as someone who dislikes travel, can I please stop doing it now? ☺

Many a time, ok, well, quite frequently at least I've needed to see what is bringing a dependency into an application or a library I'm working on. At the moment, I'm working on removing some useless dependencies for performance and misc reasons, so I'm finding information like that very helpful.

So, scripting to the rescue.

Use is simple:

burchr@virgin:~/code/scripts(master+)% genlibtree.rb /usr/lib/libQtCore.so
Dependency tree for /usr/lib/libQtCore.so
 /usr/lib/libQtCore.so
* /usr/lib/libpthread.so.0
* /usr/lib/libz.so.1
* /usr/lib/libdl.so.2
* /usr/lib/libgthread-2.0.so.0
** /usr/lib/libglib-2.0.so.0
** /usr/lib/librt.so.1
** /usr/lib/libc.so.6
* /usr/lib/libstdc++.so.6
** /usr/lib/libm.so.6
** /usr/lib/ld-linux.so.2
** /usr/lib/libgcc_s.so.1

There's a few gotchas in that it won't list repeated dependencies, only searches /usr/lib, etc - but it more or less works. Patches welcome. I hope you find it useful in your quest to remove unneeded dependencies - it is worthwhile running it over your work, at least, to see what bloat you're pulling in.

(Much thanks to many folks, but especially Thiago Macieria of Qt and other fame, for giving me a bit of a crash course in some of how shared libraries work under the hood.)

edit: I should probably note that this may not necessarily provide a full picture. Shared objects may still be loaded at runtime, and in the case of QtGui, are in the form of things like image plugins and other things. It's still useful, though.

edit 2: since I've had a few people point out that it is horrific ruby, I'd just like to note that yes, I am not in fact a perfectionist when it comes to throwaway tools I write in five minutes. Patches welcome. ;)

...now we need to let the dust settle.

So, unless you've been living in a cave, you've probably heard about the Nokia news by now. I of course have thoughts and opinions about this, not all of them clear. So I'll just stick with what I think about the future for Qt and MeeGo for now.

A lot of people around the Qt development community (some users, some contributors, and some Nokians) have been worrying. There have also been a few people asking about forking, and to them, I would say: not yet. Let the dust settle. Right now, Qt themselves don't know exactly what the future holds, but I would expect this to be clarified in the near future. Thiago has also clarified that open governance of Qt is still an ongoing project.

I don't personally see too much changing here, because despite news of Symbian's perhaps timely death, MeeGo still needs Qt, and I don't think MeeGo is in any imminent danger. Here's why.

• MeeGo is not just Nokia
  
  Intel is also involved in MeeGo, and in addition to that, there are other partners and OEMs.
  
  This will not change.
  
• MeeGo is open
  
  This means that anyone who wants to continue the work and contribute, can. There's no barriers, no licensing fees, and no patent worries. This is attractive to hardware manufacturers. Thanks to (trying) to reuse upstream components, it's also a less expensive alternative than Android.
  
  This will not change.
  
• Nokia did, right at the outset of the announcement say, they are continuing work on it
  
  Yes, it is true that they also announced that they are reducing their R&D spending on it, but perhaps this isn't such a bad thing. Perhaps lower spending will enable them to spend on what really matters, and focus on getting something out the door.

That's not that I think today's news is great, or even good - but I'd like to encourage calmness. Let's all have some time to digest the information and think about what exactly it means.
I might write more about this once I've had a chance to collect my own opinions a little more. I'm certainly concerned, and interested, but there is no need to panic.

I stumbled across a website talking about GNOME 3 today, with a few screenshots. It's not really my first exposure to gnome-shell and friends, but it's the first time I sat down and really looked at it, and imagined myself trying to work with it.
(Disclaimer: I haven't actually tried GNOME 3 as a user yet. Thus, quite a lot of my opinions might be completely off the mark, but I'm not going to be biased by having actually used it.

Those of you who have used qmake to build projects for any length of time on Linux will have probably come across the PKGCONFIG feature by now.

For those of you who haven't, here's a quick recap:

CONFIG += link_pkgconfig # enable the PKGCONFIG feature
PKGCONFIG += glib-2.0 # link against glib-2.0

While this looks simple, it has two small problems which aren't all that fun.

Firstly, it had what was really quite easily arguably a bug in that it didn't halt the qmake process if a requested package didn't exist. It would happily tell you it didn't exist, and then continue as if nothing had gone wrong, a very annoying problem in large projects:

$ cat test.pro
CONFIG += link_pkgconfig
PKGCONFIG += foobar

$ qmake test.pro:
Package foobar was not found in the pkg-config search path.
Perhaps you should add the directory containing `foobar.pc'
to the PKG_CONFIG_PATH environment variable
No package 'foobar' found

$ echo $?
0

Secondly, it wasn't possible to (easily) check for optional dependencies and enable/disable functionality depending on the result of that check.

This has now changed! Thanks to Oswald for merging merge request 1022 into Qt, PKGCONFIG will, in the future, stop on error, and (even more fun) - we can now use the shiny new qmake packagesExist() test function to detect whether a library is installed:

CONFIG += link_pkgconfig

packagesExist(glib-2.0) {
    DEFINES += HAS_GLIB
    PKGCONFIG += glib-2.0
}

// and in the code:
#ifdef HAS_GLIB
    // use glib here
#endif

Much thanks to Marco for prompting me to finally try fix this (I've eternally been annoyed by it, but someone else being frustrated by it made me leap into action), as well as to Oswald, Marius and Arvid for their review and comments during writing, and finally to Murray and Mathias for respectively reporting and trying to patch the first issue in this post, a fact I only became aware of *after* finishing my patch. Great minds think alike, it seems!

With apologies to Dave Neary for stealing his excellent word, 'antipatterns', from his talk at MeeGo Conference.

This is an opinion piece. Feel free to skip it if you already know what you're doing when writing code.

We all have things we dislike in code, sometimes it's indentation, sometimes it's a bit less trivial. One of my current pet hatreds is excessive nesting.

For those of you that don't know what I mean, if you see something like this:

void foo(bool bar, bool lol, bool hax, bool meep)
{
    if (bar) {
        if (lol || hax) {
            if (meep) {
                // do something
            }
        }
    }
}

Then you're probably a victim of excessive nesting.

If you're writing code like this then all I can say is you're probably doing it wrong.

That above example might be written better like so:

void foo(bool bar, bool lol, bool hax, bool meep)
{
    if (!bar)
        return;

    if (!lol && !hax)
        return;

    if (!meep)
        return;

    // do something
}

Generally speaking, you want your code to be like a river: to flow from one point to another, and branch off gracefully, but still continue flowing nonetheless.

In more technical terms, this makes it a lot easier to take appropriate actions at any of those junctions (if, say someone wants logging added for all of those returns in future) and makes your code a lot easier to read.

Please stop and think about what you're doing, and refactor if necessary rather than blindly adding another conditional. It might be easier to add another level of nesting, but you'll suffer in the long term. Think about it.

As a general rule of thumb, I personally think if you have more than three levels of nesting, you might need to think whether you need a new method, or whether you need to rethink your code's flow.

The astute, regular readers I manage to have might have wondered why I have recently been playing with Skia, Google's 2D graphics rendering library, notably used in Chromium and Android. Well, now that my experiment is in a semi-usable state, I decided that it's probably about time I let the cat out of the bag and started talking about what I've been doing.

After recently writing about the broken contribution process in Qt, I got a little bit inspired to see what the current 'lay of the land' of the Qt contribution ecosystem looks like. So, I did what any self-respecting hacker would do, and wrote a quick script over the course of a few hours to generate the statistics I wanted. Beware, gitstats takes a long while to run over repositories with a big history. If you want to skip the work of running it over Qt yourself, grab a copy of the CSVs I generated.

After reading Albert's thoughts about the state of openness in Qt, I felt like I had something to contribute, and contribute I did in the comments on his post, but I don't think it is enough.