Showing posts with label KDE. Show all posts
Showing posts with label KDE. Show all posts

Visualising the Ubuntu Package Repository

Like most geeks, I like data. I also like making pretty pictures. This weekend, I found a way to make pretty pictures from some data I had lying around.

The Data: Ubuntu Packages

Ubuntu is made up of thousands of packages. Each package contains a control file that provides some meta-data about the package. For example, here is the control data for the autopilot tool:

Package: python-autopilot
Priority: optional
Section: universe/python
Installed-Size: 1827
Maintainer: Ubuntu Developers 
Original-Maintainer: Thomi Richards 
Architecture: all
Source: autopilot
Version: 1.2daily12.12.10-0ubuntu1
Depends: python (>= 2.7.1-0ubuntu2), python (<< 2.8), gir1.2-gconf-2.0, gir1.2-glib-2.0, gir1.2-gtk-2.0, gir1.2-ibus-1.0, python-compizconfig, python-dbus, python-junitxml, python-qt4, python-qt4-dbus, python-testscenarios, python-testtools, python-xdg, python-xlib, python-zeitgeist
Filename: pool/universe/a/autopilot/python-autopilot_1.2daily12.12.10-0ubuntu1_all.deb
Size: 578972
MD5sum: c36f6bbab8b5ee10053b63b41ad7189a
SHA1: 749cb0df1c94630f2b3f7a4a1cd50357e0bf0e4d
SHA256: 948eeee40ad025bfb84645f68012e6677bc4447784e4214a5512786aa023467c
Description-en: Utility to write and run integration tests easily
 The autopilot engine enables to ease the writing of python tests
 for your application manipulating your inputs like the mouse and
 keyboard. It also provides a lot of utilities linked to the X server
 and detecting applications.
Homepage: https://launchpad.net/autopilot
Description-md5: 1cea8e2d895c31846b8d3482f96a24d4
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

As you can see, there's a lot of information here. The bit I'm interested in is the 'Depends' line. This lists all the packages that are required in order for this package to work correctly. When you install autopilot, your package manager will install all it's dependencies, and the dependencies of all those packages etc. This is (in my opinion), the best feature of a modern Linux distribution, compared with Windows.

Packages and their dependant packages form a directed graph. My goal is to make pretty pictures of this graph to see if I can learn anything useful.

Process: The Python

First, I wanted to extract the data from the apt package manager and create a graph data structure I could fiddle with. Using the excellent graph-tool library, I came up with this horrible horrible piece of python code:

#!/usr/bin/env python

from re import match, split
from subprocess import check_output
from debian.deb822 import Deb822
from graph_tool.all import *

graph = Graph()
package_nodes = {}
package_info = {}


def get_package_list():
    """Return a list of packages, both installed and uninstalled."""
    output = check_output(['dpkg','-l','*'])
    packages = []
    for line in output.split('\n'):
        parts = line.split()
        if not parts or not match('[uirph][nicurhWt]', parts[0]):
            continue
        packages.append(parts[1])
    return packages


def get_package_info(pkg_name):
    """Get a dict-like object containing information for a specified package."""
    global package_info
    if pkg_name in package_info:
        return package_info.get(pkg_name)
    else:
        try:
            yaml_stream = check_output(['apt-cache','show',pkg_name])
        except:
            print "Unable to find info for package: '%s'" % pkg_name
            package_info[pkg_name] = {}
            return {}
        d = Deb822(yaml_stream)
        package_info[pkg_name] = d
        return d


def get_graph_node_for_package(pkg_name):
    """Given a package name, return the graph node for that package. If the graph
    node does not exist, it is created, and it's meta-data filled.

    """
    global graph
    global package_nodes

    if pkg_name not in package_nodes:
        n = graph.add_vertex()
        package_nodes[pkg_name] = n
        # add node properties:
        pkg_info = get_package_info(pkg_name)
        graph.vertex_properties["package-name"][n] = pkg_name
        graph.vertex_properties["installed-size"][n] = int(pkg_info.get('Installed-Size', 0))
        return n
    else:
        return package_nodes.get(pkg_name)


def get_sanitised_depends_list(depends_string):
    """Given a Depends string, return a list of package names. Versions are
    stripped, and alternatives are all shown.

    """
    if depends_string == '':
        return []
    parts = split('[,\|]', depends_string)
    return [ match('(\S*)', p.strip()).groups()[0] for p in parts]

if __name__ == '__main__':
    # Create property lists we need:
    graph.vertex_properties["package-name"] = graph.new_vertex_property("string")
    graph.vertex_properties["installed-size"] = graph.new_vertex_property("int")

    # get list of packages:
    packages = get_package_list()

    # graph_nodes = graph.add_vertex(n=len(packages))
    n = 0
    for pkg_name in packages:
        node = get_graph_node_for_package(pkg_name)
        pkg_info = get_package_info(pkg_name)
        # purely virtual packages won't have a package info object:
        if pkg_info:
            depends = pkg_info.get('Depends', '')
            depends = get_sanitised_depends_list(depends)
            for dependancy in depends:
                graph.add_edge(node, get_graph_node_for_package(dependancy))
        n += 1
        if n % 10 == 0:
            print "%d / /%d" % (n, len(packages))

    graph.save('graph.gml')


Yes, I realise this is terrible code. However, I also wrote it in 10 minutes time, and I'm not planning on using it for anything serious - this is an experiment!

Running this script gives me a 2.6MB .gml file (it also takes about half an hour - did I mention that the code is terrible?). I can then import this file into gephi, run a layout algorithm over it for the best part of an hour (during which time my laptop starts sounding a lot like a vacuum cleaner), and start making pretty pictures!

The Pretties:

Without further ado - here's the first rendering. This is the entire graph. The node colouring indicates the node degree (the number of edges connected to the node) - blue is low, red is high. Edges are coloured according to their target node.

These images are all rendered small enough to fit on the web page. Click on them to get the full image.
A few things are fairly interesting about this graph. First, there's a definite central node, surrounded by a community of other packages. This isn't that surprising - most things (everything?) relies on the standard C library eventually.
The graph has several other distinct communities as well. I've produced a number of images below that show the various communities, along with a short comment.

C++

These two large nodes are libgcc1 (top), and libstdc++ (bottom). As we'll see soon, the bottom-right corder of the graph is dominated by C++ projects.

Qt and KDE

This entire island of nodes is made of up the Qt and KDE libraries. The higher nodes are the Qt libraries (QtCore, QtGui, QtXml etc), and the nodes lower down are KDE libraries (kcalcore4, akonadi, kmime4 etc).

Python

 The two large nodes here are 'python' and 'python2.7'. Interestingly, 'python3' is a much smaller community, just above the main python group.

System

Just below the python community there's a large, loosely-connected network of system tools. Notable members of this community include the Linux kernel packages, upstart, netbase, adduser, and many others.

Gnome


This is GNOME. At it's core is 'libglib', and it expands out to libgtk, libgdk-pixbuf (along with many other libraries), and from there to various applications that use these libraries (gnome-settings-daemon for example).

Mono

At the very top of the graph, off on an island by themselves are the mono packages.

Others

The wonderful thing about this graph is that the neighbourhoods are fractal. I've outlined several of the large ones, but looking closer reveals small clusters of related packages. For example: multimedia packages:

This is Just the Beginning...

This is an amazing dataset, and really this is just the beginning. There's a number of things I want to look into, including:
  • Adding 'Recommends' and 'Suggests' links between packages - with a lower edge weight than Depends.
  • Colour coding nodes according to which repository section the package can be found in.
  • Try to categorise libraries vs applications - do applications end up clustered like libraries do?
I'm open to suggestions however - what do you think I should into next?

Ubuntu One Madness

For those of you who have been living under a rock the last few months, Ubuntu One is:


...your personal cloud. But it's not just about syncing files — whether you need to access your contacts, notes or bookmarks from any computer or the web, enjoy your favorite music from a cloud integrated store or stream your entire collection to iPhone and Android mobile phones — we've raised the bar on personal clouds.
Clearly the marketing department at Canonical have been hard at work!
Unfortunately, the ubuntu one client has no support for any desktop environment other than Gnome. For a service that offers file synchronisation, having to launch a non-native client application makes the whole system rather useless. At first, this seems fair enough - a company with limited budget must allocate resources where they will do the most work. However, after a bit more digging, things seem to be in a rather poor state of affairs.

It's worth noting that the Kubuntu project is an official derivative of Ubuntu. It's listed as such on the Ubuntu derivatives page, you can purchase official canonical support for Kubuntu, purchase printed CDs through shipit, and the two projects use exactly the same software package repositories.

For a while there was light at the end of the tunnel: Harald Sitter started work on a KDE ubuntu one client. At one stage there were packages for it in a PPA, and people started using it. It even got a few independant web articles written about it. Then everything died. The PPA was removed, and development halted. Why? Harald commented on a bug report, and had this to say:

Well, Google Summer of Code is over.

And after having spent more than a week shaking a new graphical frontend for the now third version of authentication handling out my sleeve, I have learned but one thing. While you work on building something, something else will surely break in a way that will requrie half a work day to track down.
It is somewhat impossible to develop a KDE frontend while sitting outside of canonical and being in a completely different time zone than the Ubuntu One team.
On top of that I have seen crappy code design, crappy packaging, inexistance of cross-desktop awareness and cross-operatingsystem awareness and unavailability of a stable working target to develop against...

So I would put it as "I am giving up".

In the future I will devote time towards making ownCloud (a truely free "Cloud" implementation) more accessibile to the masses.

So what can we do? owncloud is not yet at a point where it can be used, and I cannot see any further development on an Ubuntu One client for KDE. Probably the most useful thing non-developers can do is to ask for clarification on the main bug report (politely please!), and make sure you click the "This bug affects me" link at the top of that page.

The real tragedy in all this isn't that there is no officially supported U1 client for KDE, or even that Canonical decided to support Windows and Mobile OSes before it's second-most popular operating system, it's that the upstream sources are (apparently) being built with no consideration to portability to other desktop environments. For a product with so many derivatives, you'd think this would be a required part of the development & planning process.

Webkit / Konqueror issue raised again

Just thought I'd point out that I'm not the only one who would like Konqueror to use webkit rather than KHTML:

WebKit in Konqueror


...It's a pity the comments are 90% flame, and 10% content.


Product Branding Critical to User Expectations

A recent post on kdevelopers.org caught my attention. In a post tagged "rant" (I love rants), "tstaerk" outlines his situation:

I am in a small team where we provide a Linux Terminal Server (LTS) for a company. It is based on NX. Every employee in this company can use the service, however, we provide it free of charge and out of enthusiasm. That means, we are not paid for setting it up nor for giving phone-support. We sometimes have 70 concurrent users on the server, that may mean we reach 500 users on the whole. The server is running KDE 3.5 as desktop environment. Recently, we evaluated - no, let me keep this understandable - we sat together and discussed the possibility of upgrading to KDE 4.

Everyone including me was against the upgrade. This is especially ashaming for me as I am spending every weekend to develop KDE. So what were the reasons?

KDE4 seems to have suffered a lot from people complaining that it's not an easy upgrade from KDE3, and to a certain extent, the complaint is justified. When KDE4 first arrives on the scene, it was really little more than a tech demo, and certainly not usable by normal users (I use the term "normal" users with all due respect - "normal" in this context means users not in the KDE development scene, and perhaps not as technically literate as the developers). However, the hype surrounding it's release meant that lots of normal users upgraded and were subsequently disappointed. With KDE4.2, we're finally getting to a stage where the KDE 4 series is actually usable as a desktop environment.

However, that's still not answering the original concern: KDE4 is still not a replacement for KDE3. Tstaerk goes on to list some of the shortcomings he sees in KDE4:

If you install a KDE 4 desktop by default, you do not have the possibility to add icons to your desktop by right-clicking onto the desktop. That would mean to us: Take 500 phone calls, explain users why it is no longer possible, explain 500 times why we do a change if it is a change to the worse... You got it, 500 times an ENOTAMUSED.

If you install a KDE 4 desktop by default, you do not have the possibility to move the clock in the panel. For me, the clock is ticking constantly on the left where I do not want it. Our users will be upset seeing another change to the worse. Yes, there is a work-around but it is so complicated that I do not want to tell it 500 times on the phone Sad

If you install a KDE 4 desktop by default, you get a strange icon in the upper right corner. No one could explain to me what it is called, but everybody said it was something about Plasma. Users will click on it and eventually hit "Zoom out". Then, their screen is filled with strange gray squares. Just imagine you have to sit on a phone and answer 500 phone calls (for no money) from users who all tell you something about "squares" not knowing they should call it "activities".

Does he have a point? Perhaps.

In some ways, calling the new product KDE4 implies an easy upgrade path from KDE3, which is misleading, since many aspects of the product have been written from scratch, and behave in a totally different manner. It would have been a better decision, I think to brand KDE4 in such a way that it was obvious that it was a new product, that would not work in the same way. This in turn might have saved a considerable amount of grief when developers found that their snazzy new technologies were being ignored, since users could not use the product like they were used to.

So, the moral of the story?

Be careful how you brand your product, especially when a newer version breaks compatibility with an older version. Is it an upgrade, or a new entity in it's own right?

KDE 4.2: First Impressions

As you may already know, KDE4.2 was released a few days ago. I was interested in writing a plasmoid in python (more on that in a future post), which meant that I had to upgrade.

So what did I think of KDE4.2 after experiencing KDE4.1?

In a word: Brilliant!

KDE4.2 is a breath of fresh air after 4.1. Many of the crashes I experienced in KDE4.1 have been fixed. For example, in 4.1, every time I opened the "Display" configuration dialog my laptop would freeze, and needed to be hard rebooted in order to get it working again. Every time I launched a full-screen application (like a game) my laptop would freeze. I couldn't kill the X server with Ctrl+Alt+Backspace without my laptop freezing... there's a whole list.

KDE4.2 fixes almost all these bugs, and even throws in some nice performance tweaks at the same time. Things feel more responsive - menus are faster to open, and some applications seem faster to load (although I haven't done any actual timing tests - so this is all subjective). Finally, it looks very nice:


It looks good, and it's responsive on my three year old laptop!

A big congratulations to all the KDE developers that made this happen. I believe I've committed a whopping 10 lines of code to KDE4, so I'm glad that other people have more commitment than I do ;)

Henry lives on

After complaining about the poor state of the web browser in a KDE platform, I have to report with mixed emotions that I've bitten the bullet and installed firefox. I'm not a huge fan of firefox - yes, it's open source, and seems to work fairly well, but it's also slow and a huge resource hog.

Who here remembers when firefox first came out? It was supposed to be a stripped down version of the mozilla web browser. The idea was that by removing the mail client, IRC chat application, and god knows how many other applications we'd end up with a smaller, faster, lighter browser. To some extent it worked. However, I'm starting to wonder if they'd have been better starting from scratch.

I challenge anyone reading this to use Chrome for windows for a week and then switch back to Firefox for good - I guarantee you you'll be pulling your hair out within a week; firefox is slow! I always assumed that the reason my browsing experience was so poor was down to my slow Internet connection, but it turns out that a fair amount of the delay is the browser.

So I have firefox - the GTK theme KDE installs looks awful, and several web sites look rubbish, but at least I can check my email...

Well, that's it for now. More to come soon (and this time I'll lose the shakespearean titles).

My Kingdom for a Browser!

This post is set to be one of the most painful entries I have ever written on this weblog. Not because the subject matter is particularly difficult, but because the technology has let me down.

The story starts with me upgrading my laptop to Kubuntu 8.10. It's been out for a while, and I'm a big fan of KDE 4, but I hadn't had a sufficiently quiet weekend in which to take the plunge. I was previously running Kubuntu 8.04, so I could have just downloaded the latest packages, but I wanted to start from scratch, for a couple of reasons.:

  1. I wanted to remove all the rubbish that I had installed over the last six months. I frequently download and install applications, only to find that they're not quite what I want. I rarely uninstall them, so over time my lhard disk fills with cruft.

  2. I wanted to wipe away all the stale config, especially as my window manager would be changing from KDE 3.x to KDE4. Besides, there's a certain pleasure to be derived from configuring a brand new KDE installation.

The install was a breeze, and for the first time ever all my laptop hardware was detected and configured correctly without any hacking on my part - even the weird web-cam, which doesn't even work in Windows XP. Life was good, until I went to browse the Internet.

KDE ships with Konqueror as it's default web browser. As far as web browsers go it's fairly nice - It lacks the large "Add-Ons" repository that Firefox has, but many of the plugins I can't live without when using Firefox are included as standard in Konqueror.



Konqueror is more than just a web browser though - the integration between konqueror and the rest of KDE is truly stunning (as an aside: this is why I prefer KDE over other desktops. Technologies like KPart and DBus are the future of desktop applications, and KDE is leading the charge in this area). As an example, if you want to search google for something, but don't have your browser window open, what can you do? Easy! just press Alt + F2 to open the "Run Command" dialog, and type "gg: " followed by your desired keywords. Hit enter and you'll launch Konqueror with the google results right there waiting for you.


Konqueror also has extensive protocol support. For example, SCP and SFTP are supported by default. Try typing something like "fish://user@host" - konqueror will as for the user password, and will then behave like a file browser for the remote machine.

These two examples hardly scratch the surface of what Konqueror can do. However - there are some very serious problems with it. Using GMail with Konqueror is torturous. First Google will give you the plain-old-HTML-only mode, since Konqueror isn't officially supported. Then, if you ask for the full version anyway you get all sorts of weirdness - and a completely unusable inbox. The solution seems to be to set the user agent to Safari 2.0, but even then my inbox seems to be incredibly slow.

Members of the KDE community have pointed out that GMail plays fast-and-loose with web standards, so it's understandable that Konqueror misses a few tricks. The Google engineers must have tested the javascript enhanced version of GMail with the most popular browsers, and left Konqueror out in the cold - and fair enough. However, the KDE developers are missing the point: no matter how good their browser is technically - no matter how standards compliant it is, it simply does not work for me - the user. I now have a browser that I cannot use to check my email (no, using the HTML-only version is not an option).

So what are the alternatives?

Before I upgraded Kubuntu I had Firefox installed. However, when I went to install it, I nearly had a heart attack. In order to install Firefox, I had to install 63 other packages - most of them gnome or GTK packages. The reason for this is simple: Firefox uses the GTK toolkit to provide a UI. I knew this already, but this early on in my new Kubuntu install I wasn't about to pollute my OS install with GTK packages.


What can I do? There are a few other options available to me:

There's been talk of a Firefox port to Qt. However, nothing usable has materialised yet, so that's off the cards.

There's the Arora browser - this is a Qt browser running the Webkit engine (which is included as standard in later Qt distributions). A quick install told me what I needed to know: also not really usable as my default browser.

Finally there's Google's offering: Chromium. However, this has not yet been ported to Linux.

So what's the underlying cause of my troubles? Without hacking the code directly, I have no idea. Perhaps this is part of the KHTML vs Webkit debacle - There's a good article outlining the whole issue here, but I'd like to quote a couple of paragraphs:

So, what's the situation? Well, it appears that KHTML will remain the web rendering engine for Konqueror going into KDE 4.0, and that it could be changed to qtWebkit as of KDE 4.1. That does not seem to be officially settled, so much as the most likely scenario. It appears that the KHTML team seems hesitant about the proposition, while many KDE developers and users alike have expressed a very receptive attitude toward seeing Konqueror user qtWebkit. And Rusin made clear to a reader that he believes the KHTML team should continue their work as long as they like.

The challenge is that Webkit, which comes from Apple, is widely tested, and is thus known to work well with a large number of websites. KHTML is not as widely tested, and, for example, GMail doesn't work well with Konqueror. Many Konqueror fans have expressed regret at having to keep Firefox around just for sites like GMail, that don't recognize KHTML. Using Webkit would solve these problems, enabling many users to stick to one browser.

In other words: "The developers are dragging their feet to implement a fix that would arguably make Konqueror a better browser". Of course, the developers involved are free to do as they please with their code, but they're dragging down the rest of the KDE platform - I now have to have multiple browsers installed to do the most basic of day-to-day tasks.

While the situation is frustrating in itself, the unfortunate fact is that similar things are happening all over the open source scene. Frequently developers get too caught up in making sure that their code is "right" (that may mean designed correctly, stable, cool, standards compliant, well integrated, or anything else the developer feels is important), and not enough time is spent making sure that the product is usable. I suppose this is one of the draw backs to a development methodology where there is no external pressure to develop your product.

Usability is king, and trumps all other concerns in a product. If it's not usable, it's no good.

piwup: A Picasaweb Image Uploader for Linux

One of my pet peeves has always been that unless you want to run google's picasa application under Linux, the only way to upload photos to your picasaweb account is via a klunky web interface that only allows you to select 5 images at a time. When I come back from a trip I have hundreds of photos, so this gets tiresome very quickly.

There is a kipi plugin that is supposed to be able to do this, but it has not yet hit the Linux distribution I am using, and I'm not about to start compiling plugins from source. Besides, half the fun is in making the application!

This is definitely not a finished application! I got it to the point where I could upload my images in a batch, but it needs more work before it's useful to anyone else. Here's a few sample screen shots:

Selecting images to upload.

Uploading the first image.

The application still has a long way to go. Just some of the things yet to complete are:
  • Remove hard coded items from the code (account details, service host, album name), and make these configurable via a nice configuration dialog. Make sure password is stored in a secure form - via the KDE wallet perhaps.
  • Make the GUI half-decent. Originally I just wanted something to work - I need to go back and do it again with a proper menu and image thumbnail support.
  • Bug fixes too numerous to mention here... this is some rouch, cheap and nasty code!

Perhaps, once I get all this done I will attempt to get it officially released into some distros. I think it's a useful application, and the kipi plugin version doesn't seem to be moving along much. Yes, I realize that I'd be better off spending my time improving the kipi plugin, but to be honest I can't be bothered right now - this was a learning experiment for me as much as it was about making an application that solved one of my problems.

The entire application is written in C++ and Qt4. The more I use Qt the more I like it. This application was simplicity itself to make, and I look forward to continued development.

On Idealism and creating your career

I enjoy working with open source software - I guess that comes as no surprise to those of you who know me. There are many reasons why I'm drawn to the open source model, including the following:

  • I like making stuff, and have the skills to do so - It's getting easier too. Application developers are realizing that making it easy for their users to extend and customize their products can only be a good thing. KDE 4.0 does this very well - you can write many simple KDE extensions in a language of your choice. Of course there are more ways to extend an application than by programming - but that's hat I'm good at.
  • Most of the time, I enjoy the community. Like any community, there are always going to be your garden variety blockheads, who seem to live for the sole purpose of making every one else's lives difficult. The open nature of an open source community makes it harder to deal with these people, but I guess that's the price you pay for freedom. On the other hand, where else can you mingle with thousands of industry experts for free? It's like being at a huge tech conference twenty four hours a day for free!
  • Open != unprofitable. Many open source projects have gone on to be the basis for a successful business model. Sure, it's harder to make truck loads of cash by treating your customers poorly, but it is possible to grow a successful business by releasing open source software. The list of companies is huge - Trolltech springs to mind - they've just been bought by Nokia for some vast sum of money, so they must be doing something right.
  • Finally, I enjoy the fact that there are no boundaries. If you have an idea for a piece of software, you can make it. There are no closed protocols to get in the way, there are no commercial pressures forcing you to take shortcuts; you are free to write your software as you wish. If you feel that writing a product that consumes massive amounts of memory and randomly crashes is a good idea - go ahead. The measure of success will be how many users use your software.
    Another point here is that this openness and strong competition leads to some very careful planning of software features. Take KDE 4 for example. Some very intelligent people have sat down together and thought about the best new features they need to make KDE even better. Don't believe me? See Aaron Seigio's KDE4 release keynote speech; it'll knock your socks off.
In some ways, that last point leads to a kind of Darwinian evolution amongst software packages. Good packages survive because they're popular, and thus more developers work on them. Bad packages languish and die. Sometimes packages are forked and sometimes packages are merged. This seething "package soup" has given us a very rich mix of packages to choose from. I can name a dozen web browsers, at least fifteen email clients, and twenty text editors off the top of my head. They're all slightly different, but they're all good software. Some might argue that we're spoiled for choice, but that's another blog post for another day!

Working as a volunteer on an open source project takes skill, commitment and determination. There are very few external motivating factors. If the project you're working on doesn't interest you, chances are you won't complete the work. The reward at the end of the tunnel is the gratitude of your fellow developers and users; not to mention some new skills you can take to your next project.

I've been involved in open source software for the last 10 years in one way or another. In that time I've picked up many skills that I can be proud of. Unfortunately, in my professional life, these skills aren't recognized by my peers - and understandably so. I have no formal qualification in the subject area, they've never seen me apply my skills in a practical manner, there may even be a lack of understanding that it's possible to gain new skills outside professional development or formal qualifications.

Which brings me to the point of this post. I want the open attitudes of the open source world to migrate to the commercial software development world. I want to have an "anything is possible" attitude towards our commercial products. We've already seen time and time again how products that started out as garden-shed projects with this open attitude have merged into multi-billion dollar products. Why can't we replicate that in a real business?

Obviously these Utopian ideals need to be tempered with the reality of running a business, but I refuse to believe that the two trains of thought are mutually exclusive. I encourage any of the readers of this blog to try to develop an "anything is possible" attitude towards product development. If you set your mind to achieve greatness, it'll happen. Why settle for anything less?


I realize that this may sound a little naive - but that's the whole point. Naivety isn't something to be ashamed of, that idealism is what makes us great; our ability to see the world as it should be, and strive to meet that distant goal is (as far as I'm concerned) fundamental to what makes us human.

Yes, we DO care!

Jeff Atwood writes a brilliant blog over at coding horror. My only gripe is that he's a .NET kinda guy - which is fine, most of the time. However, his recent post, entitled "Why Doesn't Anyone Give a Crap About Freedom Zero?" seems a little short sighted. For those of you who have never heard of freedom 0, It's one of the four freedoms that the free software foundation have set out to protect. The FSF define it as:

The freedom to run the program, for any purpose.


I don't have a problem with Jeff's love of .NET and microsoft in general, but when you post a blog with a title like that, it sidelines and marginalises everyone who does care.

Jeff - there are many of us who do care about Freedom 0 - and the other three. Take some time out of your busy schedule to investigate Linux and the BSDs. You'll find a community full of bright, innovative developers who all want to make a better computing platform.

This brings me to my second point. Okay, so this is probably really obvious to the rest of you, but I had a sudden realization the other day. It went something like this:

The reason why there are so many technically brilliant innovations found only in open source platforms (Yes, I genuinely believe that to be true) is that the pressures of software development aren't there. Commercial software vendors are always struggling to maintain a balance between allocating time to develop new features, maintain existing features, test / QA the product, and get it out the door. I don't believe that there's a single software product that was 100% complete when it was shipped. That's the nature of commercial software development. Too often the "right" way of doing things is sacrificed for a cheaper, faster way of doing things.

On the one hand this means that deadlines and schedules are met (everyone gets paid), but on the other hand the software quality is lacking. In an open source project however, there are no commercial pressures at all. Developers are left to their own devices to code what they want. Package maintainers are allowed to choose their own schedule - and who better to choose that balance between release frequency and code quality than the programmers who know the product best?


The more I look into the KDE project the more I realize that I'm right. There are some truly brilliant bits of code in there; It's a pity that they're never appreciated by the general public.

On C++ programming IDEs

I've been doing a bit of programming work under Linux for the last few days, and I'm very disappointed with the selection of integrated development environments on offer. Read on for my complaints.

First though, a bit of history. I usually write code under Windows for my job. I use Microsoft's visual studio 6. For those of you who haven't tried it, compiling code with the VS6 C++ compiler is a bit like pulling teeth. For example, Microsoft thinks that the following is perfectly valid code:

for (int i = 0; i &lt; 10; i++);
printf("After loop, i = %d", i);


However, The scope of the variable "i" is limited to the contents of the for loop (in this case it's en empty loop), and so shouldn't be available to the printf line. This becomes even more painful when you want multiple for loops within a function, and you want to be able to use the "i" variable for each loop. Under windows, you can do this:


for (int i = 0; i &lt; 10; i++)
{
// do something
}


for (i = 0; i &lt; 10; i++)
{
// do something else
}


Note that I don't need to re-declare "i" in the second loop, since it already exists? If you try and compile this code under a compiler that observes the C++ standard, you'll get compilation errors. So, how do you turn this into cross-compiler code? AFAIK the only way is to use a second variable inside the second for loop, OR to wrap each for loop in it's own additional scope block, like this:


{
for (int i = 0; i &lt; 10; i++)
{
// do something
}
}

{
for (int i = 0; i &lt; 10; i++)
{
// do something else
}
}


However, I digress from the true subject of this post. For all it's compiler digressions, the user interface actually isn't that bad. Sure, the toolbars seem to move to random positions on your screen every time you debug a project. Sure, you can't use it on a second screen because all the tooltips draw themselves on the first screen, and yes, if you want decent code completion you need to use a plugin like visual assist X, and no, there's no code folding either. But apart from all that, the UI is just right. It's not overcomplicated, it's easy to use.... simple!


So, let's look at KDevelop, KDE development environment. I have several problems with it:

  1. Code completion requires the user to jump through waaaay too many hoops. As far as I'm concerned it should be turned on by default, or, if that ruffles too many feathers, have one checkbox to turn it on. I shouldn't have to root around in the KDevelop settings, and project settings, add the library include directories I want to use for the project, exit KDevelop, install ctags, re-load project, tweak settings, and then find that code completion is actually not that brilliant.
  2. The User interface is way too cluttered. Many of the menus are so full of entries that they cascade off the bottom of my screen. There are so many toolbars and sidebars that I can barely see my work. Many of the sidebars don't even work properly! The documentation sidebar seems particularly useless. I could probably find out what I have to do to get it going, but my point is that it should work out of the box! When I fire up KDevelop, I want to write some code, not mess about with the environment.
The best development environment should be completely transparent to the programmer. OK, so none of the IDEs I've used to date achieve this, but a man can dream, right?


In the mean time, I'm going back to my old IDE: Kate, with the scons build system, activated from the console, and gdb as a debugger. What more could you want?

Maintaining Binary Compatability

It seems to be common practice for software development companies to patch individual parts of a released product. Usually this means distributing a second installer that creates new shared object (.so or .dll) files, so the next time the application in question runs it loads the new object files, and thus runs the new code.

In practice this is a great idea - it means that companies don't need to re-release and re-ship the entire product. Unfortunately, it's not always that easy. The biggest problem is that the new libraries must be binary compatible with the old ones. Essentially this means making sure that all objects within the library are the same size as they were, and that things like vtables haven't changed.

For a while now I've been looking around for a definitive list of guidelines to help me maintain binary compatible libraries. I finally found it on the KDE website.

Behold: Binary Compatible Issues with C++

Anyway, I thought that might be useful to some of you. Enjoy!

New Tools!

I've started to use scribefire to publish posts on this blog. The built-in blogspot editor was just too clunky. Ideally I'd like to use a separate KDE application, but the ones available simply aren't good enough for me to use yet.

Speaking of KDE, I'm currently downloading the KDE sources from subversion - I'll see what small contributions I can make.

Finally - I know this is old news, but if you haven't already, head over to the GIMP website, and check out gimp 2.4. It's been a long time coming, but it was worth the wait. The new version contains (amongst other things) a whole raft of bug fixes, improved icons, scalable brushes, and (my personal favorite) a new and improved selection tool!