In the GTK+ 3.0 branch, GDK saw quite some changes recently. Firstly, a last part of Benjamin Otte’s rendering-cleanup was merged, which removes GdkDrawable. Now that GdkPixmap and GdkImage were already removed before (in favor of using their Cairo counterparts), there’s no need to abstract these away behind a GdkDrawable. Only GdkWindow is left to deal with basically.
The other large refactoring is the “GDK backend” branch that was recently merged. Before, you could only select a single backend at compile time, resulting in a libgdk-<platform> and libgtk-<platform>. GDK has now been refactored to properly separate the backends from the generic “core” GDK code. It is now possible to compile multiple backends into the GDK library. Perhaps in the future loadable backends will be possible as well. This work is in particular interesting for linking in both the X11 and Quartz backends on Mac OS X (for testing, comparing and debugging), and X11 and the upcoming Wayland backend on Linux. I am pretty eager to try a both X11 and Quartz enabled GDK on Mac OS X, but still some work is left to do sorting out the platform-specific code in libgtk. But once that is done, it should be possible, the GDK part is already done.
All in all, I am pretty excited about all the attention GDK has received in the last months after being neglected for a long time. In GTK+ 3.0, GDK is much easier to port to other platforms than it was before. I hope a trend has been set and GDK will be further simplified in the future.
I have tried my best to keep the OS X backend up to date over all these changes and refactorings. It seems to be working fine, so it is in shape for GTK+ 3.0. Let’s say it is at least as good as the last GTK+ 2.x releases, maybe even better.
I really hope we are done with refactoring for a while now, so I can focus again on reviewing and implementing missing features in the backend :).
Over the last few months Tristan van Berkom has been working on GtkCellArea. GtkCellArea can be described as a generic class that can be used for layouting and rendering sets of GtkCellRenderers. Before, widgets dealing with GtkCellRenders, such as GtkTreeView, GtkCellView and GtkIconview, all implemented this by themselves. In GtkTreeView, most of this code was hidden in
gtk_tree_view_column_cell_process_action(), a function that not many people dared to touch and a function more fragile than a box of wine glasses.
I tried to support Tristan by showing him around in the more obscure parts of the GtkTreeView code, showing him some interesting corner cases and by reviewing the new code. As soon as it was possible I attempted a migration of GtkTreeViewColumn to use the new GtkCellArea. To my surprise, this was much less painful than I had expected, which is a good thing :) After that we had to spend a lot of time polishing things and fixing corner cases, finally everything was merged in the GTK+ 3 branch. Furthermore, Tristan has worked on porting GtkComboBox/GtkCellView and GtkIconView over to use GtkCellArea as well. We expect these changes to be merged in time for GTK+ 3.0 as well. What is great is that we managed to do all of this without introducing API incompatible changes, so existing GTK+2 code using GtkTreeView will continue to compile and work as is.
I think the end result is great, the GtkTreeViewColumn code got a well-needed refactoring, code duplication amongst GtkTreeView/GtkIconView/etc. has been reduced and we have paved the road to properly support height-for-width in GtkTreeView. We hope to work on the height-for-width support in the near future, this will not be trivial task as we will have to take a closer look at the validation machinery of GtkTreeView and perhaps revamp that as well. During this process I hope to incorporate some changes I made to the validation code in a local branch, with these changes it is possible to remove the idle handler that goes over all rows in the GtkTreeModel in the background for measurement by trading in scrollbar accuracy and perfectly sized columns. With this, we can support large models without having to explicitly enable fixed height mode (in fact, this mode can then be removed). There is a possibility that we end up moving this code into a separate class (maybe GTK+-internal at first) as well, which can be re-used by GtkIconView to support displaying very large models (currently GtkIconView will likely fall apart when you try that).
Rests me to thank Tristan for the hard work!
 Footnote for users of large GtkTreeModels: However, the entire model will still be fully iterated because of the reference counting mechanism in GtkTreeView/GtkTreeModel. Properly supporting lazy loading of models will require different changes to GtkTreeView but mainly to the GtkTreeModel interface to have real support for this.