Kristian Rietveld

With 4days3hours7mins idle time on IRC I returned last Monday from a Campingflight to Lowlands paradise 2007. Having been there for the fifth time in a row, this year I also enjoyed myself very much despite the crappy line-up. We'd love to see much more punk and metal bands, which seem to be on the decline at this festival. Anyway, we made loads of fun on the festival terrain and did see some of the bands: Heideroosjes, Madcaddies, Editors (partly, I think it was kinda boring because I don't remember what they played), Kasabian (partly, and from the outside while chatting), Eagles of Death Metal, The Killers (partly, because it was boring), Brand New (these guys have an identity crisis or something, seriously, such crap), Games in Concert (partly, this was quite cool: a big Dutch orchestra playing music from video games), The Rifles, Turbonegro, The View, Interpol (this concert, was really, really good; superb sound and lightshow), Kaiser Chiefs (a big contrast, boring music, bad vocals, annoying light show), Balkanbeatz/Russendisko (this is awesome party music), Funeral for a Friend (partly, really as bad as the name), The Answer, Nine Inch Nails (partly, not my kind of music, but the sound blowed people out of the tent), Motörhead (sat outside and enjoyed), Arcade Fire (partly, scarily happy people), Tool (which was just way too awesome). So that's it, I guess we should go again next year if they manage to get a better line-up ;) Oh oh oh, and before I went to GUADEC and vacation and Lowlands this year I finally saw Me First and the Gimme Gimmes! Awesome band, really. (more blog entries later since I am a bit behind).

The last months have been very busy. Lots of stuff to do, exams, little stress and not feeling all that well mentally. Fortunately fixed most of the stuff up in the week before GUADEC by dropping some things, something that was really, really needed. This took a long time, because I felt really bad about dropping it. Eventually got over it and hope people will pick up the work (which I am sure they will). Heard I passed one of the exams (which I thought I ruined), don't know about the other one yet. Bought a ticket for Lowlands (5th time!!!) anyway, even though I might have to do a re-take the day after. Then off to GUADEC. Had a really good time there, meeting up with a lot of people. I think my talk went okay as well, my slides can be found here for the people that are interested. I will post notes/minutes of the GTK+ meeting we had at the GUADEC Monday ASAP. Flew back to the Netherlands on Sunday, and right now, on Monday, I am sitting in Berlin having a beer. We don't know where we will go next since we didn't book hotels yet, but it looks like a nice start of a really needed vacation. I will be trying to work a lot on my BSc thesis though, since I want to receive my BSc in September… I also started hacking on a new application!! More on that later, it is not very special though and people are telling me that I should really start using something called “git”. My co-workers are still in the process on learning how to pronounce the Dutch “sch”., they are getting there though.

People will remember my post on column resizing from about a month ago. I did some more work on this over the last few days, based on the nice suggestions left in the comments of that blog entry and some discussions with people. I ended up implementing something which basically only recalculates the expand values when the width of the tree view itself changes, or the number of expand columns. So if the user resizes a column, the expand values will not be changed and the weird/chaotic behavior is gone. You can find the results in the latest patch in the bug (#316087). A small side effect at this moment is that when the expand flag is turned off, the column will be “reset” to use its original requested size (see the last comment in the bug report for some more detail). I am not yet really sure if I like this. Opinions appreciated of course. At this stage I am pretty happy with the behavior, so good chance that this patch will find its way into GTK+ 2.11.x soonish.

When I am busy hacking on bugs (which is about the only thing I do these days when I have time for hacking …) a thing which I use very, very frequently is cvs/svn annotate in the viewcvs web interface. For files as big as gtktreeview.c (almost 15000 lines), it is impossible to remember every little detail of the code; why is it like this? which parts are affected when I change this? Before changing things I usually check the history of that code portion using annotate, to see what kind of changes were made before. With a few little clicks I can find reasonings, old bug reports with stack traces and test cases. I know you can use svn annotate from the command line, but having it in a web interface with cross reference is much more convenient. For me annotate in a terminal is useless. I was pretty disappointed to see that on svn.gnome.org, annotation is not possible in the web interface. Is there any way this can be made possible? I am pretty sure a lot of other people would also appreciate to have this feature back, since it is so useful for tracing back changes. (This has been filed as #395908 — together with the request for the old “theme” of the revision log page, which is much more clear IMHO). For now I continue using cvs.gnome.org for this, but at some point the amount of changes between the last cvs version and svn will be so big that this won't be useful anymore …

Well, it finally happened, the new tooltips API hit GTK+ trunk. Ever been annoyed by the fact that GTK+ does not support tooltips on insensitive widgets? Ever wondered about an easy way to implement tooltips for specific tree view rows? The new tooltips API solves these and other issues, to get started quickly see the example application aka test program: gtk+/tests/testtooltips.c. There will be some more improvements in trunk as the code matures; probably a bug fix here and there, and the positioning code isn't quite right yet…

The infamous column resizing bug, #316087, has a good amount of duplicates. While it might look like a programming bug which needs to be fixed, there is actually much more involved: what you see happening is actually "correct", but it looks really strange. I've been looking at some other toolkits to see whether they support a likewise expand flag and how they solve this issue. More details under the cut, since it's a pretty lengthy piece. The columns in GtkTreeView support live resizing, in fact non-live resizing isn't even supported. In general this works very well. However, GtkTreeViewColumn also has an "expand" property. All extra horizontal space left after allocating size to the columns is equally divided between all columns with the expand flag set to true. This is really useful in cases where you want to give the most important column in your view the extra space, when it is not the last (rightmost) column (by default this rightmost column gets the extra space). For example: if you are writing a media player, you would probably set the expand flag on the column holding the track name / title. What's the big deal here? Create a tree view with two expandable columns, make all columns resizable, look what happens when resizing. Let me elaborate. Suppose we have the following columns:

   [column0][expandable1    ][column2][expandable3    ][column4] 

If you try to resize the column “expandable1” (using the handle between “expandable1” and “column2”) you will notice that as soon as you press the mouse button the column separator will jump to the right. What's actually happening here? Well, the column is set to use-resized-width mode, and the resized-width has just been set to the actual width of the column PLUS the extra size from expand (that's where the mouse cursor was when you pressed the button). Of course, since the column is still expandable, it receives extra space on top of the resized-width. What happens if you try to resize column2? Column2 grows, while both expandable1 and expandable3 shrink. Because column2 is growing, there is less extra space to divide between expandable1 and expandable3. It looks really weird, but the behavior is 100% correct. A possible bug fix which came to mind: as soon as a user resizes a column, turn expand off on all columns, and for all columns set the width to their requested width plus the extra space allocated to them. This should actually work if you apply the patch from comment #26 in #316087. Automatically turning off the expand flags is not the nicest solution of course. After a suggestion from Nickolay, I started to look how other toolkits handle this. I've only had a quick look at some toolkits; if there are errors in my quick analysis or if there's a toolkit with a really nice resizing mode missing out, please let me know. From a quick look I figured that Windows does not support live resizing, so it falls out of the scope of this discussion. Java's Swing has a pretty thought out approach to resizing (I've looked at JTable here). The actual resizing happens in the doLayout() method. If the table itself resizes, the change of width will be distributed to all columns in the table. If one of the columns changes width, JTable will do resizing according to the resize mode set by the programmer:

• resize-off: column widths won't be adjusted, a horizontal scroll bar is used when the sum of the column widths is bigger than the width allocated to the table.
• resize-next: use the column after the resizing column to absorb the change in width. With this mode the column separator between adjacent columns can be changed without affected the other columns.
• resize-subsequent: use all columns after the resizing column to absorb the changes.
• resize-last-column: adjusts the size of the last column only.
• resize-all-columns: with this mode all columns are adjusted, also the one which is being resized. It does look a little awkward.

The minimum and maximum column widths are respected if they are set. You can find some nice graphics which might make everything more clear here: http://java.sun.com/products/jlf/ed1/dg/higp.htm#999756. JTable does not seem to have an expand flag for columns. Cocoa's NSTableView has likewise resizing modes (although a little different here and there) since Mac OS X 10.4. It does not support an expand flag on columns. ETree/ETable does not support an expand flag like GtkTreeView does. Instead you set an expansion value and columns all get a share of the extra space based on their expansion value. Interesting is that it seems that only columns marked as resizable are allocated extra space. When live resizing, only columns to the right of the column being resized actually change width. So all in all it looks pretty similar to the (default) “resize subsequent” mode in JTable, however in ETable only resizable columns are modified. QListView in Qt3 has a resize mode property too, however it only supports none, all or the last column (deciding which column will be resized to fit the list view). Qt4 does not seem to have support for this; when the layout is updated columns are sizes based on a per-column size hint. Both do not support an expand flag. Being able to set a resize mode like in JTable in GTK+ might be nice, but the only thing it can solve is nicely resizing columns without increasing the width of the list view (ie. avoiding a horizontal scroll bar). Introducing this won't help our expand flag problems, since also with a resize mode resizing will look weird. (Unless somebody comes up with a brilliant special resize mode with takes expandable columns into account). Another interesting observation in the bug report by John Bryant says that the expand flag is actually only really used to get nice sizes for the column “on start up”. After that the expandable flag is of course still active, but the changes most probably aren't that huge. In summary, after writing this piece, I actually think that disabling the expand flags after the first column resize by the user is a fair way to solve this problem. We should keep in memory that adding resizes modes might be nice in the future. Suggestions, comments are of course welcome. If nobody has better ideas I will probably end up committing something like the patch in comment 26 mentioned above.

This has been going on for a while already :) The fixing spree actually began already 2 months ago, and I decided it was about time to finally write a GtkTreeView scrolling test suite. I've been wanting to write such a test suite since my scrolling bugs fixing spree around GTK+ 2.6 and 2.7. Back then I had a bunch of test cases in my ~/testcases/ and before committing I would check whether a fix would break any of those test cases. A lot of work and prone to errors. Around that time I was already thinking about combining those test cases to one test app. Of course it never happened. Of course I also lost track of the test cases I was testing with. So during Imendio conf this year (back in November) I slowly started working on this test suite. Finishing it took much, much longer than expected and I kept finding small bugs and adding tests. But finally I ended up with a pretty useful test application, it already helped me a lot when testing a bunch of fixes which will go into GTK+ HEAD today. For those interested, the source is here (reading it in a browser messes up the formatting btw): http://www.babi-pangang.org/~kris/testcases/testtreescroll-26dec06.c It does need some more improvements at this point, it relies on the font used and the speed of the machine for example. And of course I intend to add a test case to this thing for each new scrolling bug I get. When GTK+ gets a proper testing framework I hope to integrate this test suite with that testing framework. I hope most bugs are gone now. If you find any regressions or new scrolling bugs in HEAD, please file a bug. So what's next? Writing a test suite for tree models. I already have some notes on this, hopefully I can write the code during January. (I suspect I will be mostly busy partying during the SVN cut-off :) ). (And of course, a happy 2007 to all of you!)

Oh anyway, if you want to play with the OS X port of GTK+ on your Intel Mac, you want to have this Cairo patch: https://bugs.freedesktop.org/show_bug.cgi?id=8939 From what I've been told Cairo might switch to another Quartz backend soon. From reading the code it looks like that one suffers from the same issue but I haven't been able to test for myself since the new backend seems to be far from compiling on my machine …

Long overdue entry (yet again), but hopefully not really too late. For the people living in a cave: we released GTK+ 2.10 right after GUADEC, together with GLib 2.12. You can find the tarballs at the usual place. At GUADEC we had a gtk-dev meeting in real life. I took some notes which you can find here. It includes the plans for GTK+ 2.12 (I will update the website soon, promised). There's some nice stuff coming up for 2.12 and we hope to release 2.12.0 around January 2007. There were also a couple of GTK+ related presentations at GUADEC; Alex and John talked about the new printing API, Emmanuele about the new recent files API, Mitch about using GTypeModule, Tim and I talked about GTK+ 2.10 and friends in general. You can find links to the slides of those talks at our new papers and slides page over at gtk.org. Also, 3.0 is not really in sight at this moment. We created a tracker bug (#347771) to keep track of bugs which require incompatible changes. I don't have much more to tell, life after 2.10.0 is not much more than fixing bugs and waiting for the 2.10 branch to be created ;). I will be back once the first 2.12 features are trickling in.

Now the first development release, 2.9.0, has been released, I guess it is time for a new entry (: We've been pretty busy and a bunch of big features landed:

• The recent files code landed. (Has a nice test app called testrecentchooser in the tests/ subdirectory).
• The printing branch has been merged to HEAD (see Alex' blog entry). Also has a nice test app in the tests/, called print-editor.
• The asynchronous file chooser branch (kris-async-branch) has also been merged to HEAD.
• Also the federico-filename-branch has been merged to HEAD. There's a button left of the path bar now, when clicked it will present a location entry in the file chooser dialog.

Also some smaller changes:

• Yet another cell renderer got added: GtkCellRendererSpin. I guess the name says enough, you can change the value of this cell with a spin button.
• Dialogs have been made more consistent with the HIG. (See bugzilla #163850).
• You can now cancel drags of scrollbars and other GtkRange derivatives with ESC.
• The GIF loader in gdk-pixbuf now only loads the first frame if you don't ask for an animation. You will only notice this change when you are working with multi-MB animated GIFs (for example byzanz screencasts).
• GtkTreeView got some new properties, which allow you to customize it a bit more. The properties in question are “show-expanders” and “level-indentation”. You can, for example, use these to do grouping as demonstrated in the testgrouping app in the tests/ subdirectory.
• The discussion on the new tooltips API continued, read the latest thread here.
• And a lot of bug fixes, really.

Like Emmanuele said earlier, you can find all feature additions and improvements in the NEWS file. The NEWS file is not as detailed as it usually is, because there are way too many changes from GTK+ 2.8.x to 2.9.0. Note that with GTK+ 2.9.0 the binary interface version has been bumped to 2.10.0 (from 2.4.0). This means that all third party modules (theme engines, input method modules, pixbuf loaders, file system backends) will have to be rebuilt so they are installed in the right place. Sorry for the somewhat short entry, but I am really going to stop here before it gets out of hand ;)