Category: Uncategorized

Okay, I am actually getting hacking done (okay okay it is more like reviewing) and I just committed the fix for #316087 “Resizing columns is chaotic” to gtk+ trunk (finally!). Should be in the next 2.13 releases. This patch does modify the internals of tree view column size allocation, so if people could give the latest gtk+ from trunk a test drive that would be really appreciated :) By the way, you can find the slides from yesterday's GTK+ state of the Union here. The plans from the release team for GNOME3 sound cool, exciting times ahead :)

My talk “GTK+ State of the Union” at GUADEC has been moved from Friday morning to Thursday 14:30 (the cancelled keynote slot). This was noted in the schedule on the GUADEC website before, but unfortunately this schedule was reverted to the original version as also found on the badges this morning. But the move of the talk is still on :) Minutes from the GTK+ developer's meeting we had yesterday will follow soon, hopefully early next week. Ah yeah, and during GUADEC I am hacking on Bug 316087, or better known as “column resizing with expand=TRUE columns is entirely fucked up”. Seems we are very close to getting this fixed now. I will probably also hang out at the parties during the upcoming days, so see you all there ;)

I've been meaning to blog again for a long while, and I finally managed to sit down and do it. The last few months have been very, very busy. I got inspired in some way and started studying three times as hard, which is a good thing since I finally manage to get a lot of things done there. This week I finished two more master courses, for both of which we did some interesting stuff. For the first one I have been looking at very low-level cache optimizations (esp. strip lining/loop blocking) with somebody else; learnt a great deal of new stuff and gained experience. The other course was about grid computing; for the presentation and project part I have been focussing on data storage in grids. I've been looking at iRODS, which is an open source system for building data grids. It is a very interesting and promising project, but not yet ready for production deployments. I should probably put my report on this online at some point. Furthermore, my thesis is finally almost done. In the coming weeks I will be working on finishing another course which I had to leave behind for a while at the end of last year. At least the end is coming in sight, I hope to have my BSc and MSc degrees before mid next-year. Being very busy with studying is nice and all, but it means I had zero time left for spare time (GTK+) hacking. I hope this will change in the coming weeks and get my “getting things done” attitude from University work also applied to GTK+ hacking ;) I am going to look into:

• Getting the column resizing with > 1 expand=TRUE columns patch updated, fixed and committed in trunk. (finally)
• Design and implement a proper API for doing DnD (with multiple rows) in GtkTreeView. This should include making it possible to DnD between tree views and apps. (finally)
• Look into improving the rubber banding behavior as Christian Neumair talked about in his blog. As is stated in the related tree view bugzilla bug about this, probably need to move over the cell_process_action() refactorings from my experimental branch to trunk and then this might be much easier to fix. Moving that refactoring over means writing a good automated layouting test.
• Look into properly fixing the editing mess. We need a better means to distinguish between committed/cancelled editings.
• Actually write about the plans for a simple tree view wrapper that I've discussed with Johan and Emmanuele during the hack fest.
• Continue hacking on my experimental tree view branch. More on this later.

I thought I had more for this list, but this will keep me busy for a good while anyway ;)

In his last post, Murray writes that GtkTreeView calls gtk_tree_model_iter_next() for every row. This is indeed true, for the simple reason that the internal state keeping of GtkTreeView needs an exact internal representation of what is being displayed. This representation is in the form of an RB-Tree, wherein there is a node for each visible row. The definition of visible that we use here includes all nodes that are outside the current scroll area that is being shown. Visible distinguishes collapsed and expanded nodes from each other. Each node in this RB-Tree contains the properties of that row, such as its height, is it a parent or not, is it selected, etc, etc. In order to build this tree, we need to iterate over all nodes in the model, hence that iter_next() is being called for all these nodes. Even for a million rows this is not a problem, building the RB-Tree is quite a fast operation. This has all been discussed at length recently at gtk-devel-list: see here. The main performance problems have always been the measuring of all rows, which is something you can avoid by using fixed-height-mode. A lot of people have heard about me working on some experimental tree view improvements, this is also true. In my experimental branch fixed-height-mode has been removed, since the need for validating all rows has been removed. It can handle 4 million rows just fine. So, do we really have to put the entire model in the internal representation? This is actually an unanswered question. It of course greatly simplifies the implementation of GtkTreeView, but nobody says that it would not be possible to modify GtkTreeView in such a way that this is not required anymore. I haven't looked at this in depth myself yet, maybe at some point in the future when I have time and finished studies and and and … (I spent a lot of time on University stuff these days, it has been years since I have been so much motivated to work on finishing studies). While Philip and Jürg's ideas on iterator types and GtkTreeModel improvements are certainly interesting, it is not a (complete) solution for this particular problem. It will especially easify the implementation of data sources/tree models and their testability. The solution for large data sources is really in the view part and not (so much) the model part. Time for more Minix hacking now …

In some of the feedback we've received so far we feel that some of the points on the slides have been misunderstood. All people that haven't been in Berlin of course miss a part of the story, since the bullet points don't tell it in full. We've just done some more touches to our paper describing our vision on the GTK+ and you can read it here. As you can imagine, the paper is much more elaborate than the slides. If there are more questions/suggestions after reading the paper, be sure to let us know!

People here figured that today is GTK+'s 2.0.0 6th anniversary, woo! We go to celebrate this later tonight. Today most of the talks have been about introspection. I spent some time talking with ebassi and jdahlin where they showed me the “simple tree view wrappers” that exist for perl and python. Both seem to be similar and very nice. Hope to look into creating something like this in C soon (maybe this week still?) to make the simple uses for GtkTreeView much less time consuming to program. My hacking project seems to be progressing nicely. pixbuf-demo is running fine already with all graphics properly loaded via CoreGraphics. It loads photoshop files nicely as well. Next steps are getting it to do progressive loading and support animations and then a first version should be ready to hopefully commit in trunk. After that I will look into getting saving support done :)