Archive for the ‘Gnome’ Category

Code Quality

Tuesday, August 31st, 2010

The recently released GLib 2.25.15 contains a new class for dealing with dates: gdatetime.c. With apologies to Pauli: That code is not right. It is not even wrong.

The code basically claims to handle date+time+timezone. Such code, in principle, makes a lot of sense in Glib. But even a cursory scan through the code reveals numerous grave problems:

  • It reimplements the date handling code from GDate. Badly and buggy: even fairly simple things as advancing one day does not work. Actually, advancing by zero days does not work either.
  • Code like g_date_time_difference and g_date_time_get_hour as well as the representation of time-of-day makes it clear that the code does not and will not handle timezones properly. The author does not understand things like daylight savings time and the fact that some days are not 24 hours long under that regime.
  • Code like g_date_time_printf makes it clear that the author does not understand UTF-8. Here is an outline:

    for (i = 0; i < utf8len; i++)
    {
    const char *tmp =
    g_utf8_offset_to_pointer (format, i);
    char c = g_utf8_get_char (tmp);
    [...]
    }

    That has got to be the worst way to traverse a UTF-8 string seen in the wild. And note how it mangles characters with code points outside the range of “char”.

  • There is no error handling and the API as-is will not allow it.
  • The code obviously was not tested well.

Why does code like that make it into GLib? The code was reviewed by Glib maintainer Matthias Clasen. I do not think he did a very good job. (He is busy asking for patches, but not busy applying patches. Certainly he avoids talking about substance. In any case, the code does not need patches, it needs to be taken out back.)


* * * * *

The bigger question is how you control code quality in a large project like GLib/GTK+. It is a simple question with a very complicated answer probably involving test suites and automated tools. I do not have anything to say about test suites here.

In the free software world the automated tools mostly come down to the compiler, sparse, and valgrind. (Let me know if I have missed anything substantial.)

  • “gcc -Wall” or some variant thereof. GLib and Gtk+ use this and use it reasonably well.
  • “Sparse”. There are signs that GLib/Gtk+ have not been run through sparse for a very long time. Gio, for example, appears to never have been tested.
  • “Valgrind”. Valgrind is probably being used on GLib/Gtk+ regularly, but each new release seems to be putting new roadblocks in the way of making effective use of Valgrind. In modern versions you cannot make Gtk+ release its objects, so Pango will not release its stuff and the font libraries in turn will not release its. Do not get me wrong: exit(2) if a very efficient way of releasing resources, but not being able to — optionally — release resources manually means that you do not know if your memory handling works right.

In short: Glib and Gtk+ are slowly moving away from automated code quality checks beyond the compiler.

I used to run GLib/Gtk+ through Sparse and Purify. Over time I got the message that bug reports based on that were not particular welcome.

Goodbye F-Spot, Hello Picasa

Tuesday, June 2nd, 2009

I am giving up on F-Spot.

It was a really promising application, but it has never been able follow up on that great start. The worst thing is that it is sluggish. Operations that should be instant — like displaying the next image — are not, but take half a second. (Getting a new camera did not help there!) I used to think it was just my old laptop, but with a new laptop that excuse does not fly anymore.

I have now tried Picasa. It is crazy-fast! For now, I am going to use that. The biggest problem was migrating the F-Spot tags. That problem was solved with the help from a Robert Brown on Google’s help forums.

Basically, you need this script to create album files and then blow away Picasa’s database to force a regeneration.

The Gtk+ File Chooser Dialog, Take II

Monday, February 23rd, 2009

OpenSuSE 11.1 updated the Gnome File Chooser and it now looks like this:

file-dialog2

Recall that my premise is that the file chooser’s function is to help the user choose files. By my count, the area used for files is 29% in the above dialog, including header and scroll bar. That simply is not right! Why does the “Places” section (which I rarely use) and its buttons take up that much space? Further, what does the path bar give me that adding the path into the location entry and putting “..” into the file list does not give me?

Things get a lot worse if a file preview is added. Here’s how uploading the above image looked in Mozilla:

file-dialog3

There is room for an incredible 2-4 letters of the file names! And the full “Places” and path bar sections, of course.

Could someone please defend the Gnome File Chooser so I do not have to suggest taking it out back and having it shot!

(I do not take comments at my blog, but you can probably find an email address somewhere.)

The Gtk+ File Chooser Dialog

Wednesday, January 21st, 2009

Whenever I update my OpenSuSE installation, the Gtk+ File Chooser Dialog get worse. This is how it looks for me on OpenSuSE 11.1 when used from Gnumeric. It looks more or less the same from Gedit and Mozilla.

Gtk+ File Chooser Dialog

Gtk+ File Chooser Dialog

I hope I am not breaking new ground when I claim that the purpose of the file chooser is to help the user choose a file. How is that going to happen when the area used for files is less than the size of one button?

I really hope other people are seeing something sane, but this is with a vanilla install, I think. (Note: I mention OpenSuSE 11.1 for reference, not as an assignment of blame.)

Applications

Wednesday, July 16th, 2008

I my optics, computers are here to get certain jobs done. That means it is all about applications, not eye candy: bouncing icons, themes, semi-transparent windows. My real-life work desk is not transparent, and I do not use semi-transparent paper.

Producing large applications is a lot of work, so when I write a piece of (hopefully) well-designed code, I want that code to stay written. I do not want next week’s GTK+ deprecation to come along and, effectively, cause my code to bitrot. (and I really do not want to write two different pieces of code for the job: one for “old” GTK+ and one for “new” GTK+.)

Moving from GTK+ 1.x to GTK+ 2.x was painful. I do not need anything like that again. Talks about breaking API every 3-4 years and advice like “Stay up to date, adapt your application code early” (and, by implication, often) is a clear indication that keeping applications running is likely to mean spending much time cleaning up after someone with an attention span of a few years.

Maintaining code like GTK+ is not hard. Calling it hard because you want to play with some new toy is deceiving.  Maintaining can be tedious, but if you do not want to maintain, please do not start writing new GTK+ code. You will surely abandon that prematurely too, so you have no business writing library code. Instead, go write a useful application: if you abandon that, I probably do not have to care.

tab = lose

Sunday, July 13th, 2008

The best thing about tabs that I can think of is that it will keep certain people from doing more harmful things like changing the gtk+ api for no good reason.

(The header line is a translation from Danish into English.)

Themes Are Evil, Part II

Saturday, February 2nd, 2008

In a previous post, I showed how a GTK+ theme engine can corrupt memory of any application unfortunate enough to be used with it.

In today’s edition, our guest star is the Qt theme engine. It does not, as far as I know, corrupt your memory or otherwise make your innocent application crash.[*] Instead it changes how your program works. For example, for Gnumeric it changes how numbers imported are handled.

If you import the number “8,5″ in a decimal-comma locale then you would hope to get eight-and-a-half, right? Well, with the Qt theme you get eight and we, the Gnumeric team, look incompetent. The problem arises because the Qt theme, quite reasonably, initializes the qt library. During that, less reasonably, the following code gets executed:

setlocale( LC_ALL, “” ); // use correct char set mapping
setlocale( LC_NUMERIC, “C” ); // make sprintf()/scanf() work

I am not kidding. The Qt library thinks it should change your locale. What on Earth have the Trolls been drinking? Impure home destilled booze in large quantities?

This problem in various disguises have had us puzzled for quite a while and only very recently was the Qt theme identified as the triggering factor. Once that happened, it was not too hard to locate, but before that we have spent maybe 40 hours looking for this bug. The workaround is to set up a one-shot idle handler that resets the locale properly when the gui comes us. (Repeat this for every GTK+ program that displays or accepts floating-point values.)

The Qt theme people never caught this. If they are mostly “theme” people I can understand, but if they are mostly “Qt” people they really should have known. In either case, it is another exhibit for the case that the GTK+ theme model is seriously flawed.

[*] Well, if you use threads it might. The Qt library calls setlocale to change locale and that’s not allowed in a threaded program.

Progress in the Printing World

Friday, January 25th, 2008

With gedit moving from gnome-print to gtk-print there is probably only one gnome-print user left, namely abiword.

This is amazing progress in the sense that instead of using gnome-print which is basically unmaintained and doesn’t work on Win32, we can now simply use gtk-print which is basically unmaintained and doesn’t work on Win32.

Murray, A Retraction is in Order

Monday, November 26th, 2007

(By blog and email.)

Murray, a retraction of that post is in order.

Here is why: I do not think, and you have certainly offered no evidence, that you are competent to diagnose the mental state and ditto ailments of other people. If you in fact do have such credentials from a respectable medical school, now would be a good time to display them. (And to inspect an inquiry from the relevant ethics committee.)

The truth or falsity of the rest of your post is utterly irrelevant. I do not know if it is true or false; I do not care. You have evinced seriously bad judgment and deep character flaws.

main-menu

Wednesday, November 14th, 2007

I have noticed that main-menu on my system is a bit of a pig. It takes up something like 30 cpu minutes per day. That is kind of crazy considering I don’t really use it much. Certainly not every day. So what does it do?

  • It reads /proc/mounts and /proc/partitions. It then stats everything mentioned in there.
  • It appears to be talking to NetworkManager via dbus.
  • It stats about 100 directories like /usr/local/share/icons

And it does all of those every few seconds.