Category: GNOME

I’ve processed some more GUADEC 2007 videos, including most of the keynotes. I’m slowly getting through the remaining, but each video takes several hours to process, so please bear with me!

Behdad Esfahbod – Co-maintaining cairo.ogg
Stormy Peters – Would you do it for free again.ogg
Robert Love – Google and Open Source.ogg
Matthew Allum – Clutter Foo.ogg
Doc Searls – Some observations about Linux and Business.ogg
Bryan Clark and Havoc Pennington – Online Desktop.ogg
Alex Graveley – Crafting 3.0.ogg
Michael Meeks – Impromtu IO Grind Talk.ogg

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.