colin@
colino.net

I gave a look at various places to see which kind of feedback the last release got. So far, not a single crasher has been reported, nor any outstanding bug. Cool.
People wrote:

• How about [ghostscript-viewer] for Sylpheed-Claws 1.9.x?
• I still have two major wishes regarding cut-n-paste and reformatting. [...] I’m not trying to nag, but can you please also answer my wish-list question?
• Will there be a binary release of 1.9.12 for Debian experimental branch?

Not… disappointed… at all. ;-)

Ok, we already got some nice feedback:
<ticho> mm, claws truly rocks now
<ticho> whoa, guys, did you feed the new claws some steroids or something? it’s much faster with larger amounts of emails in a folder.

And there, too.

Paul beat me to the blog announcement. But he forgot to link to the release notes :-)

I’m quite happy about this release. I hope people will be too.

Given that I had a really hard time finding a simple example on how to use libgnomeprint and libgnomeprintui, here is a little hello-world type example for it.
libgnomeprintexample-.tar.gz. (Yes, it’s quickly thrown together so there’s not even a version).

Just type ./configure && make && ./libgnomeprintexample

And let’s hope this will be useful to someone :-)

Sylpheed-Claws’ current printing system sucks hard. It works with a command, so if you want to get something nice-looking, you’ve got to elaborate something like “txt2html %s | html2ps | lpr”. Quite user-friendly. If you just use “lpr %s”, you’ll get a nice sheet of paper straight out the eighties, with wrapping in the middle of the words, nice utf-8 stuff instead of extended chars, and so on.

So, I spent a few hours googling for documentation on libgnomeprint and libgnomeprintui, found next to nothing. The API is not really straight-forward and an hello-world type example would have been nice to have.
This morning, probably after having googled for a magic combination, I found that Tomboy had a print plugin with an API that I liked at the first glance:

void gedit_print(GtkTextView *text);
void gedit_print_preview(GtkTextView *text);


After having taken the four relevant files from their CVS and modified our configure.ac and Makefile.am, this worked perfectly nicely in less than one hour.

Thanks Gedit authors, thanks Tomboy authors!

As we’re in feature freeze, this will be commited later. If you want to try it sooner, I’ve put a patch there.

The rule “when it’s really slow and shouldn’t be, the cause is really simple” verifies once again. Yesterday evening, I thought I’d fix Sylpheed-Claws’ “Select All” which was really slow. It was fast on a ~100 mails folder, took 11 seconds on a 5000 mails folder, and I killed it before it finished in a 25000 mails folder. Looked exponential, so I thought gtk_clist_select_all walked a list in the wrong way (like appending to a GSList instead of prepending). I downloaded GTK+ source and proceeded to reimplement gtk_clist_select_all in our summary_select_all. Sadly enough, the GTK code seemed optimized enough. No blatant O(N^2) list walking…

But looking at the gtk code, I seen gtk_clist_select_all selects each row one by one, which has the effect of firing an tree-select-row event. And our summary view registers such an event handler, in order to do what should be done when you select a mail. Our summary_selected callback wasn’t buggy enough to display mails when the selection was multiple, which would have been a good reason to be slow, but it did call summary_status_show at the beginning, in order to update the “X items selected, N kBs” label we have. Of course, to do that, summary_status_show walks the selected list!
As summary_selected returns early without calling anything when the summary view is locked, the optimisation finally looked like:

+ summary_lock(summaryview);
  gtk_clist_select_all(GTK_CLIST(summaryview->ctree));
+ summary_unlock(summaryview);
+ summary_status_show(summaryview);

And voilà, instant-select-all in the biggest mail folders I could find.

Something things are more easy than they look like…