Quick and Dirty HacksHacks, code, etc…

After reading and listening (LR) to Jono Bacon rant on about the direction of GNOME a subject on which I whole heartily agree and something you’ll see me working on in the future it seems strange to me that GNOME don’t have teams to deal with desktop continuity. Usability is one thing, and is the big buzz word being thrown around at the minute and since guadec. However usability being an important issue as it is, it must be connected to continuity of the desktop. In movies they employ people to make sure that if a actor/actress is wearing a red top in one scene, he/she doesn’t end up wearing the blue top featured later in the movie in the next scene even though the filming of the two scenes are back to back. Wardrobe and continuity make this happen, continuity ensures that the flow of the film isn’t damaged by inconsistencies that viewers will notice.

There is no difference between continuity in movies and continuity of software, in fact to illustrate this point I have filed two bug reports which show this endemic behavior of GNOME developers. Something which FDO was supposed to prevent.

The bugs, #426195 – Creating launcher inconsistency in nautilus, and #42196 – Creating launcher inconsistency in alacarte are perfect examples of this problem, where continuity flaws creep into GNOME, not because there is a lack of standardisation, not because the developers overlook an issue, but because the requirement for a continuity team has been overlooked. Developers working on one project, may import some code from another project to prevent duplication of work, thats cool… However, if a third set of eyes doesn’t look at both, all three, four, five or however many instances of the same kind of action is being undertaken then continuity is lost.

The standards exist, the developers write good code, but there are the little things, the finishing touches… Things which may throw a user, its not merely usability thats important but continuity of applications ranks up there too.

UPDATE 22/4/2007: Upon closer inspection it appears that the two bugs filed boiled down to the same code in GNOME panel. So I wrote a patch, that should apply to any recent gnome-panel sources. The patch is now in bugzilla, hopefully it will be triaged and accepted soon

pirut (pronounced pirate) has been introduced into fedora over 5 and 6 to provide a GUI package manager that wasn’t complete crippleware like redhat/fedora has been since the grand old days of 7 where they actually had some good tools although not repo enabled (eg. gnorpm).

I hate pirut with a passion now, and this isn’t because its a bad application, its because it is so horrendously badly written that it shouldn’t have been released.

So here’s my list of complaints;

• Why don’t ALL packages on the system, and available show up in the groups view, this is the case when using yum repos in anaconda too. This means that you can’t install a nvidia driver on install because it isn’t displayed on install.
• Why is it, when I click a checkbox to install an application, it takes about 5-6 seconds (of which time I am unsure whether or not the event has been registered) to turn the checkbox on. Here’s a tip for redhat devels, when an event occurs, process the VISUAL aspect of the event FIRST, then do whatever else needs to be done, don’t leave your users in the dark!
• yum-updatesd creates hellish conflicts and way too much CPU usage on startup and during desktop usage, a hidden process in the background is not where I want 100% CPU time to go, and on the odd occasion blocks using pup?!?!?
• puplet could at the very least wait until NetworkManager has connected my wireless before complaining that it can’t update the system. The logic of this is obvious, sort it out!!!!
• The user interface of the package updater doesn’t actually expand properly, I actually filed a bug about GTK expanders and why using them in certain situations is broken. #141834 even though this is broken, and is known to be broken and is obviously NOT visually appealing when implemented in pup redhat STILL use it!!!!. I have a fixed glade file which doesn’t exhibit the problem evident in the current release. I need to make this patchworthy however.
• Half way through an install/update pirut/pup regularly starts using 100% CPU time and stops progressing forward for 20-30 minutes. Most of the time I kill it and start again.
• It takes 10 – 15 clicks to apply before pup begins to realise that I’m trying to get it to do something, this is again related to redhats complete disregard for what the user may be thinking while the software sits there doing nothing. The effect should be immediate in as much as it desensitises the pup window and pops up the updater progress box.
• WHAT THE FUCK DOES IT NEED AN UPDATER PROGRESS BOX FOR!!!! PUT THE FUCKING PROGRESS BOX IN THE PUP/PIRUT MAIN WINDOW, this fixes many issues, for instance focus thieving dialogs are not good!
• Why does pup use 300Mb of memory? This just doesn’t make any sense at all, in all seriousness redhat really need to fix this, pup cripples a system because of this.
• The icons in pirut should be themable.
• Search filtering is very seriously slow. I wrote this example in 20 mins, I was going to put some really nice time benchmarking stuff, but couldn’t be bothered when I saw how fast it was on its own. Its easy to make search fast, as long as you have a fast array to filter, and don’t start employing rediculous procedures during the filter!

Overall, pup doesn’t keep the user adequetely informed about what its doing, uses way too much CPU time and memory. Admittedly some of these issues may come down to yum but when the user interface is as clunky as pirut/pup its what we see that gets the flack.