Thomas Wood

There’s nothing quite like the moment you finally crack a programming problem you’ve been working on for hours or even days.

So what is the problem I have been trying to solve that has kept me up so late at night? See if you can tell for yourself. It may not look like much once you spot it, but it has had me scratching my head for so long I just had to share it with everyone.

I hope I can squeeze it in for the next version of GNOME. After all, it’s an issue that has been present since the very earliest versions of GNOME 2.

Before:

After:

Rob opened a UI Review tracker bug for Anjuta the other day and asked me on Monday if I could help out. I had a quick look this morning and filed about eight new bugs in total. By lunchtime, Johannes Schmid has already been fixing most of them. So, if you see any HIG violations in Anjuta, especially now that it is going to become an official part of the GNOME platform, please add them to the depends of the tracker bug!

ps. The new library.gnome.org makes browsing the HIG really nice, but looking at the screenshots is a bit like looking through a short history of the early days of GTK+ 2. Maybe I’ll find some time to update them all to look a little more consistent and modern!

Design Decisions*

I was doing some bug fixing for the control center today and came across bug 442168. It is asking for a preference to be added to the control center that would allow users to change the size of icons in menus, buttons and toolbars across the desktop. I can see at least two possible valid use cases for this:

1. Users with low screen resolution want to reduce the size of their icons to maximise efficiency in screen estate
2. Users want to increase the size of the icons for accessibility reasons

These are obviously two conflicting use cases, where an option would be necessary to satisfy them both. However, there is some disagreement over whether this is a useful enough option to add to the UI.  I can see that to some people this would be a greatly beneficial, and that if the option were to be added, even more people may end up using it. On the other hand, not including this option doesn’t have any  serious drawbacks and in fact, helps us maintain a more clean and simple user interface.

A Quantitative Approach?

The problem here is that the advantages and disadvantages do not clearly out way one another. Could we therefore find a more quantitative approach to making this decision? Firstly, we might want to look at the percentage of users who would find the option useful and then compare with the following thresholds:

• 0% to x%: Not many users will choose this option, therefore not useful enough to consider adding to the UI
• x% to y%: Some users will want to change this option, therefore useful to have
• y% to 100%: Lots of users will use this option, we must have made a bad design decision somewhere

In addition to the number of users who would consider using an option, we must also look at the importance of the option per user. For example, I would suspect that some accessibility options are used by only very few people, but these options are of critical importance to those using them. The resulting decision would have to be made on an interpolation of the two sets of figures.

So the bigger question is, how do we (as the free software community) go about finding these statistics in the first place, and what is the best thing to do if  we can’t agree on a decision?

* If you haven’t already done so, read Havoc’s paper on UI design choices as background

According to ohloh, I made my 500th commit to GNOME today (although it hasn’t quite caught up with today yet, and CIA says it was my 662nd). After a brief period of inactivity I’m finally getting round to doing some things for GNOME again – and most importantly I’m doing it for fun. I think it’s probably fair to say I was pretty burnt out after helping organise GUADEC, but it’s also good to take a little break every now and again. Remember folks, you should only keep volunteering while you still find it enjoyable.

It’s probably slightly ironic that I was introduced to ohloh through Matthias’ blog post on the possible privacy implications. Although I’m relatively happy with the information shared about my contributions to Free and Open Source software, I remember it took me quite some time to come to terms with the fact that everything I did was so visible and easily accessibly to anyone and everyone. Has the Internet bred a community that is complacent to privacy, or do we just accept there are no guarantees for any data we place on-line?

An early Christmas present; I’ve put six more GUADEC videos on-line:

Adam Jackson – GNOME-Xorg Integration.ogg
Antonio Albanes – Large scale gnome deployment at schools.ogg
Eduardo Lima – Porting GNOME applications to Maemo.ogg
Ian McKeller – Developing XUL Applications.ogg
Naba Kumar – Integrated communication framework for GNOME – elements of Telepathy.ogg

Trent Lloyd – Avahi.ogg

Still none of the main hall talks (including keynotes) are available yet because I haven’t been able to fix the audio streams. However, Deigo is helping me to work out if there is some gstreamer foo I can use to correct the problems.

We had a great art.gnome.org SoC project this year. While we didn’t finish the new site completely, we made good progress towards a new community based website. The code can be found here: http://svn.gnome.org/viewvc/art-web/branches/art-web-3/. It uses the CodeIgniter PHP framework.

However, it seems that I’m lacking the motivation and time to get it finished and up and running. I’ve worked on and off the art.gnome.org site for almost five years and I’m pretty sure it’s time someone else could take charge.

I’m willing to help out where needed, but I need someone I can pass the baton on to. So, if you are enthusiastic about GNOME artwork and enjoy working on websites and PHP and working on art.gnome.org sounds interesting to you, then please contact me. My e-mail and jabber account is “thos at gnome org” and I am usually on irc.gnome.org as thos.

I’d love to see art.gnome.org more active again.

P.S. I’m not interested in any “art.gnome.org should use $foo CMS” or “art.gnome.org should use $foo coding language”, I’m only interested in hearing from people actually willing to make a valuable contribution.

Anjuta used to be a bit of a disappointment and besides,  who could tear Vim or Emacs out of the hands of any worth while developer?

Well, since I have been doing more and more GTK+ development lately and I don’t having the brain capacity to remember every single GTK+ function and parameter, someone told me Anjuta had both function name completion and parameter hints. So I thought I would give it another go.

To my (pleasant) suprise, it has come on a long way from the last time I tried it. Even the Glade integration is pretty nice and I was impressed with it’s autotools integration and the way it can import existing autotools projects. Just need some vim keybindings and modeline support now…

So here’s a screenshot of my first (well, maybe second) new project done entirely from scratch in Anjuta:

It’s also my first attempt at using git. The repository is published here: http://www.thos.me.uk/git/icon-theme-editor.git/

Note that it only loads files at the moment, it doesn’t edit or save them yet. Well, what did you expect, I only started it yesterday. Patches and bug reports are most welcome.

At GUADEC 2007, the raw video from cameras was captured directly onto laptops which at the end of each day were copied onto a 500GB hard drive.

At the end of GUADEC, this drive went back to OpenAdvantage and was connected up to the network there. The plan was to allow the coordinators to download the videos and encode them in a suitable format.

Unfortunately, at some point the drive was disconnected from the network. Paul was on holiday for the next week. After that, he started his new job at OpenedHand and was staying in London for the next two weeks. This meant he couldn’t get back to OpenAdvantage to find out what had happened to the drive.

After this, it transpired that the disconnection was simply because of a reorganisation in the OpenAdvantage office. However, the two other 500GB drives OpenAdvantage had bought at the same time as the one used for GAUDEC, had now completely failed. Paul was obviously a bit concerned that the GUADEC video disc should not fail as well.

So, Paul very carefully took the disc back to his house and went in search of some drives to backup the data with. He purchased two 450GB drives and started copying the data. This amount of data takes a long time to copy between two USB drives.

Anyway, Paul was able to bring one of the 450G drives to London where I picked it up. The next task was to decide on compression rates and how to actually created the finished video. The last problem was arranging appropriate hosting and bandwidth. And remember, this all had to be done in our spare time.

So finally, nearly six months on, I have started encoding and uploading the videos. You can find the ones I’ve done so far, here:

http://download.gnome.org/teams/guadec/2007/videos/

They are encoded at a bandwidth that should mean most people on broadband are able to stream them easily. Of course, people are more than welcome to re-encode them and upload to any favourite video sharing website.

One thing you will notice is that none of the videos from the main hall are yet available. This is because the audio level on them is very quiet and only on one channel. I would be grateful if someone could suggest a suitable gstreamer pipeline to fix this.

We all like to have a little grumble about our favourite distribution from time to time. As it happens, I don’t have a favourite GNU/Linux distribution (they all have good and bad points), but with apparently less than 9 days to go until Fedora 8 is released, I really hope they fix the bugs I’ve been having.

Although I use other distributions on my personal computer, I have always kept my work laptop on the latest stable release of Fedora. Mainly because they have historically patched GNOME much less than other distributors and are fairly good at keeping up with the most recent GNOME (and possibly because that is what Mallum originally installed when I joined – apparently we needed to try building Poky on something other than Debian/Ubuntu!).

A week or so ago, I “upgraded” to the development version of Fedora to see if the new version of NetworkManager would help alleviate some of my problems. Unfortunately things haven’t gone quite so smoothly. Here’s a list of things I’ve noticed:

The Good

• Suspend and hibernate on my T43 are now working again. They both mysteriously stopped working after an update to Fedora 7.
• There is a great looking new GDM screen
• The new default web browser home page is a huge improvement. It’s now actually useful!

The Bad

• Power Manager now brightens my display when idle, despite the fact I have explicitly told it not to do anything when the computer is idle. I wish Power Manager would not touch my brightness settings at all, since it doesn’t know anything about the ambient light. (Could be bug 483134)
• NetworkManager now frequently crashes whenever I try to interact with it. It seems this has something to do with the Neo1973 acting as a usb network device. I see the following on the terminal:
  ** (nm-applet:8834): WARNING **: Error getting vendor info from HAL: No property info.vendor on device with id /org/freedesktop/Hal/devices/usb_device_1457_5122_noserial_if0
• The package management application frequently refuses to help me, insisting that another application is using the package database even though there is no sign of one working.

The Ugly

• Sorry about this one, but it’s possibly a little pet peeve. The new GTK+ theme in Fedora 8 is not to my liking at all. It is clearly unfinished (progress bars for example) and the gradients on the buttons look (to me) like blisters on human skin. Not only does it look bad, but I seriously doubt the code quality is as good as the engines in the gtk-engines module. There are a lot of very important things to consider when writing a GTK+ engine, as it will be running on every single GTK+ application. Just look at the number of bug reports and issues associated with Ubuntu’s “Ubuntulooks” engine as an example of what can go wrong (and the original Clearlooks had it’s fair share of very nasty bugs too). The engines in gtk-engines are rigorously tested and very well maintained, so I really don’t see any advantage in using yet another theme engine.

I know this last point will probably upset some people, but I really want to encourage distributions to work with upstream projects when working on themes and artwork. The look and feel of GNOME should not be the differentiating factor when choosing a distribution, so I would love to see more upstream efforts to help provide a better and more consistent visual identity for GNOME.

And please, if anyone can direct me to Fedora’s bug tacker, I would be very happy to file my issues there. Unfortunately, fedoraproject.org doesn’t seem to give me any clue on how I send my feedback to the developers. OK, I’ve found Fedora bugzilla now. Still, please let me know if any of the above problems have already been reported so I don’t end up adding duplicates.