While researching the feasability of this idea as a project I hit a pretty big road block. I need to find an audio toolkit that will allow me to work with audio files, of different formats, in a fairly simple way whilst at the same time exposing enough complexity for me to do various mixing between audio tracks.

Fortunately, several such toolkits exist, the most attractive of which being GStreamer. GStreamer is the audio framework that the GNOME Desktop is built upon. It’s pluggable, allowing support for new formats to be added and removed independantly of the applications that use them and it’s very stable. However, traditionally, the language of choice for GStreamer applications is C - which I don’t know, so I decided to check out the various language bindings available.

Unfortunately, the only stable language bindings are all for dynamic languages (Python, Perl, Ruby etc.) - the bindings for both Mono and Java are unstable and deemed “suicide to use”.

This is a shame because I would really like to develop this project in a strong-typed language, especially C# - more specifically: Mono.

Unless the bindings for C# are completed and stabilize before I begin my project I’ll just have to make do with Python. Don’t get me wrong, I like Python. I would just rather have the debugging support of the Mono CLI behind me to help me iron out problems.

However, something that has probably slipped most people by is exactly how useful the Facebook Platform is to Facebook themselves. Most of the core elements, the Wall, Groups, Events, Photos etc. (but not Profiles and Pages) are all in fact applications that run on the Facebook Platform. Most people don’t notice because they’re enabled by different, but it affords Facebook many advantages.

For a start it enables them to create the Platform using use-driven development. While I don’t know whether this is true, it’s certainly a brilliant opportunity to aid development. I also makes the entire system far more modularised - by decreasing the number of things that are part of the core of Facebook, they’ve reduced the amount of code that has to be maintained by the core Facebook team. Problems with the default applications, for example, a bug in the Wall, can be easily isolated and therefore fixed quickly and easily.

As with bug-hunting, modularisation allows them to very quickly create new features without having to dabble with the core code and potentially break one of the most popular websites in the world. New features can be tested by releasing it as a non-default application and, once it has been put through its paces, deployed en-mass.

All of this gives Facebook the opportunity to comepletely crush rivals like MySpace, and with relative ease. Obviously, they’re not there yet, but they launched “Pages” only 4 days ago, alowing groups/organisations to setup specialised profiles, and already around a quarter of my favourite bands have their own pages.

Together with the clean look and easy to use interface, Facebook’s extensibility and modularity has exactly what it takes to bury MySpace.

This has me thinking: Can this computing model of abstraction and modularisation be applied as a general business model to real world products? And if it can, can it with much success? The answer to both questions is probably “no”, but I’d certainly be interested in finding out.

Obviously, I will be installing some non-Microsoft software - Adobe Flash Player was among the first things I installed - but my productivity software will largely be developed by Microsoft.

I started by setting up the native Vista applications - Windows Calendar, Windows Contacts and Windows Mail. I couldn’t help but notice that Windows Mail actually seems to handle my various IMAP accounts better than Evolution - a supposed rival to Outlook.

The integration between Calendar, Contacts and Mail is intriguing, I can’t pass judgement until I’ve used them for a few weeks, but if it works well it’ll certainly increase my productivity.

On the subject of integration, I know they’re legally bound not to bundle Windows Live products with Windows Vista but it does strike me as odd that the Windows Live crew hasn’t explored the possibility of integrating better with Vista.

I would love to see Windows Live Messenger automatically tie my Live account to my system account, using it’s contact details and display picture without having to select one myself.

Similarly, it’d be nice for my Messenger contacts to be added, in some form, to Windows Contacts. Even if they were fairly basic, it would give me a starting point to go through and add more details for each contact.

Windows Live Writer, I must admit, is one of the better Windows Live products. It’s one of the best desktop blog publishing tools I have ever tried. Upon opening it I was prompted for my blog address, username and password. Writer automatically set everything up using just these 3 pieces of information. That’s simplicity.

Windows Vista itself works like a charm. That’s right. No driver hell, no sluggish operations, no crashing and very little nagging from the controversial User Account Control (UAC).

Reflecting upon my move to Windows XP back in 2001 - just after its release - this experience is much smoother. While critics have lambasted the operating system for its poor compatibility, it is miles ahead of the situation Windows XP was in this long after it launched.

While it’s certainly not the best thing since sliced bread, and is not going to cure cancer (although it may play a part), I feel confident that Windows Vista and most mainstream applications will be stable enough for most companies to roll out once Service Pack 1 is released next year.

Finally, to everyone who immediately discredited Windows Vista before using it for a week or two, I pity you. Sure it took them far too long to produce it, but that doesn’t change the fact that it’s significantly better than Windows XP. I’m not going to explain why, Vista’s critics will just have to use it to find out.

This started off with me spending 2 days hacking together a small PyGTK tool to mount SSHFS filesystems. It quickly became apparent that my limited PyGTK skills had left me with some pretty ugly code. So, with a little more experience under my belt I decided to start again.

However, this time I’m not just going to tackle the mounting and unmounting of SSHFS filesystems - instead I plan to build a tool for mounting and unmounting any FUSE-based filesystem (whether it’s local or remote) and have it automatically mount selected filesystems on start-up.

I now have a basic specification which calls for the following major components:

• A new file, ~/.fusetab, that will contain definitions for all your FUSE-based filesystems.
  • It will need to contain: FUSE driver (e.g. sshfs), filesystem path (local or remote), mount point and a flag to determine whether it should be automatically mounted on startup.
• A PyGTK frontend to manage the filesystems defined in ~/.fusetab.
• A fast, simple Python script to parse ~/.fusetab on startup and automatically mount the specified filesystems.
• A shared library, likely a simple Python class, that encapsulates a filesystem with methods to mount, unmount and get the mount status.

There will need to be hooks defined in the shared library that allows drivers to define additional creation and pre/post mount/unmount behaviour (i.e. when mounting over SSH for the first time it should attempt to append your local ~/.ssh/id_rsa.pub to your remote ~/.ssh/authorized_keys in order to remove the need for a password on-mount).

FUSE drivers will also have to instruct the shared library exactly how to mount filesystems. This I haven’t fully researched but I’m hoping that the Python FUSE bindings themselves will have something to do this elegantly, otherwise I’ll have to have the driver define the CLI program to execute for mounting filesystems.

If anyone reading this has any thoughts on this, especially regarding its design, please comment, I’d love to hear from you.

It’s a shame in many ways because it leaves the Gnome desktop feeling incomplete. Recently I’ve been thinking long and hard about the Gnome control panel applets (cutely abbreviated “capplets”) and how best to tackle them. Generally, I’ve found them to be a bit fragmented, with often related options in totally different capplets or with seemingly vital options missing entirely.

That’s not to say there’s a lack of good software and developers out there making such programs for Gnome, but unfortunately they appear either unwilling or unable to integrate this work in to the Gnome desktop itself.

Case in point: Today I found out about sysinfo, an application for displaying useful system information in a user friendly way and is miles better than the standard “Device Manager” capplet. It’s written for Gnome in GTK+, so in theory, there’s no reason why it shouldn’t be a part of the Gnome desktop. It would require fairly minor changes to integrate it in to the Gnome desktop as a control panel applet so why not?

Sysinfo isn’t alone, there is a multitude of applications and especially applets that provide much needed functionality and yet hasn’t been included in the Gnome desktop. All that would be required is someone from Gnome to contact these developers and say “Hey, you’ve got a pretty good thing going there, with a few small changes/additions this’d fit great in to the Gnome desktop.”

If I was approached by a seasoned Gnome-er and asked to incorporate my application in to Gnome, I’d leap at the chance. Especially if it’d fill a whole and make the Gnome desktop just that little more complete.

I’ve mostly ported the theme and all the old posts, but unfortunately I don’t think I’m going to be able to post the comments.

The theme is pretty slap-dash at the moment. It hasn’t been tested in anything other than Firefox 2 on Linux so it’ll likely be a little broken, especially on ancient installations of IE.

UAC, in principle, is a good step towards making Windows a better and more secure operating system, unfortunately in practice it proves more of an irritation to users, who find themselves clicking “continue” out of habit. Reminiscent of software installation licence agreements.

OS X and most desktop Linux distributions have been using a similar approach to allow temporary administrative access for years to much success. However, both of these require more from the user than UAC, needing a password to “continue” whereas UAC merely prompts the user to click a button.

The problem is that administrative access is required by far too much on the Windows platform. Each time something requests administrative access. Want to delete a shared shortcut from the start menu? You’ll need administrative access for that! How about playing Battlefield 2142 online? Sorry, Punkbuster requires administrative access (why!?).

The truth is, it’s not UAC that’s the problem. It’s all the various programs for Windows that assume and have always assumed that they have full administrative access to the machine. It’s a long standing loop-hole that Microsoft have finally closed and now developers have to actually put some thought in to their software before coding.

Of course, Microsoft themselves have this lesson to learn as many actions in Windows Vista require administrative access when they probably shouldn’t.

Hopefully, in time everyone will learn that they’re not in charge of the computer. The user is.

Where’s my native GTK+ widgets on Gnome? Qt on KDE? Or, dare I ask, native widgets on Windows, which is by far their largest demographic. I admit, Firefox looks worse on OS X than it does on any of the above, but that’s no excuse.

At the moment, on Gnome, it’s a toss up as to which is better, Firefox or Epiphany. Epiphany, with it’s native GTK+ user interface, is much faster and integrates well with the desktop, but Firefox, with it’s add-on system and huge development community is much more powerful.

We need a clear winner. We need a GTK+ build of Firefox.

Compare the release notes of the last 3 releases of Gnome with that of Gnome 2.18:

• Gnome 2.12 release notes
• Gnome 2.14 release notes
• Gnome 2.16 release notes

The 2.18 release notes are important because they are a single page, whereas the others are all split over multiple pages - each one of a length that rivals the entirety of the 2.18 release notes.

Are the release team getting lazy in their documentation? Or has Gnome development slowed significantly over the last 6 months resulting in a fairly dull release.

I’ve heard reports that there are “numerous performance improvements” in 2.18, but they’re not documented in the release notes - unlike in previous releases.

Does this mark a change in the detail to which releases are documented? I hope not.

Step up Glade

Glade is probably one of the most underrated development tools for Gnome. It makes prototyping an interface a sinch, with no need to worry about typing out laborious GTK+ code; move everything around, add and remove features from your design and mess around with settings quickly and easily until you have something you’re happy with.

Once you have your final UI design, you have two options. Either use libglade to set up your application UI or convert the glade UI in to real GTK+ code by hand.

The former is far simpler, but the latter adds more flexability, removes redundant widgets and a dependancy on libglade and increases performance.

Converting the Glade XML by hand isn’t as much of a chore as it sounds. Widgets in the Glade XML only define options that have non-default values so you simply need to arm yourself with the GTK+ documentation, run down the XML and implement each widget, adding children where necessary.

Guest starring: Anjuta

While Glade is great for prototyping a UI, testing your UI (Glade appears to render slightly differently to GTK+, so it’s a good idea to run the prototype properly), converting it to GTK+ code and of course, writing the actual program code is a necessity. While gedit, vim and emacs are all fine for the job, creating a source tree and build system for your application can be a bit of a nightmare.

There’s nothing worse than spending more time debugging your build scripts than your program code.

Anjuta makes it all easy - while it may not generate the most optimal build scripts - it does a good job of providing you with a source tree that will build without the need for any tweaking. Which is perfect for testing your UI prototype quickly and without fuss.

I’m just starting out with GTK+ programming and, in fact, C; but I’m already finding tools that make the learning curve so much less steep.