Morten Welinder

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.

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.)

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.

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.

(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.

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.

…although I am willing to entertain the idea that they are a necessary
evil.

Themes in GTK+ land are, simplified, arbitrary pieces of dynamically
loaded code that is hooked into the drawing layers of widgets. There
is no fault isolation, so when (not if) a theme does something naughty,
the application crashes. Then the user curses a few times and blames
the usual suspects: the screen/keyboard and the application.

Have a look at bug 438456. Theme code used in, for example, the industrial theme released various
kind of memory allocated by GTK+ using the wrong function, in this case g_free. Result: instant memory corruption in all GTK+ applications! Not good.

I do not think it is realistic to redesign the theming of GTK+ at
this point in time, but we really need to do something about
stability.

• Theme authors need to be extremely careful with their coding.
• Theme authors should use the full range of automated testing
  at our disposal: running under Valgrind and separately with G_SLICE=debug-blocks during some kind of theme torture test is a bare minimum. For every release.

I realize that I am asking other people to do some work. I do not feel too bad about that, though, because it is theme code that is causing my application to crash, causing people to lose data, and the blame is sent my way.

Ok, go ahead and tell me how wrong I am.

I wanted to know when a certain identifier was introduced in goffice.
It turned out that it was fairly simple:

  git grep -w GO_FORMAT_MARKUP `git tag -l 'GOFFICE*'` -- '*.h'

That commands searches all .h files from all Goffice releases.
It is very fast: about 0.5s (cpu time) on a fairly slow machine.

How do I do that with SVN?

I’ll happily add myself to the chorus: switching to SVN? Someone must
have been drinking out of the potty.

If we are going to suffer the pain of a conversion, then we have better get a lot out of it.

• Retraining. We all know cvs’ quirks. (And my fingers like to type c-v-s.)
• Lost history. None of the conversion tools are perfect.
• Recoding. Custom scripts will have to be recoded.

These apply to all systems (except cvs). The trouble with SVN
is that it is hard to see it as more than a stepping stone.

Dave, if the only argument that people have against it is that “everyone knows that distributed’s better” is what you believe, then you have not been listening. Start with KeithP’s write-up saying, in part, that (1) SVN lacks corruption detection,
(2) Git is a whole lot faster than SVN, and (3) SVN is a space pig compared to Git.

By the way, why is it relevant whether most distributions include the system by default? We expect, from time to time, that developers have HEAD versions of various off-site libraries, so surely we can get the same developers to obtain a recent copy of Git (etc.), right?

So can we please have git and gitweb running somewhere on gnome.org
with access to, say, ~user/public_git/ directories? I promise that I will not complain too much about SVN if that happens.

I have been trying out f-spot recently and I must say that using
it gives me one of those rare warm fuzzy feelings inside.

It has well designed interface with relatively little clutter.
It by and large does what I want it to.
And it does not crash or hang for me.
It does not even spew a lot of scary warnings in my session log file.

I can find nits, sure I can. In fact I just filed a pile of them, but we are talking the would-be-nice department here.

• Tagging an image should not cause a re-render.
• I want to be able to assign hot keys for tags.
• I want f-spot to detect duplicate images.
• Ctrl-+ ought to work for zooming in.

Nice job on this, guys!