Kristian Rietveld

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

So we are in Berlin now with a good amount of people for the hackfest. The apartments are nice, the wireless is working out fine so far and there are plenty of snacks and beer. Though we seem to have run out of beer already, but I heard rumors it's going to be fixed soon ;) One problem is though that the weather outside is too nice to actually sit inside all day and hack. However, it looks like this is going to change Tuesday/Wednesday. This morning we started with presentations after we finished transforming one of the living rooms into a “theatre”. Everybody just fit in the room and it's a pretty funny sight :) I had the honor of starting off the presentations track this morning. I think a lot of people have actually been thinking about the future of GTK+; what new features to add and how to move forward. We hope to have a lot of discussions about all these ideas everybody has. At Imendio we've also been thinking about where we want to go with GTK+. We presented our “vision” on GTK+ during this mornings presentation; my slides can be found here. We hope to have more discussions about this this week. Later on we will post a document with a more elaborate description of these ideas. As for hacking, I was recently inspired by dom's and arc's GDI pixbuf loader. For this week I've decided to do something similar for Mac OS X. The CoreGraphics framework has an ImageIO library with loading and saving support for a lot of image formats. I hope to get a pixbuf loader using this running during the hackweek. It will greatly simplify the build process for GTK+ on the Mac as well as shipping applications.

In complex widgets there are often so many possible actions and so little keys. In GtkTreeView this certainly holds for the arrow keys. Since its inception, the arrow keys have been used to move the focus cursor (the dotted rectangle). For GtkTreeView configurations with editable and/or activatable cells (think entries, checkboxes) the left/right keys will allow you to navigate between them. When there is a horizontal scrollbar, the horizonal arrow keys also do scrolling. This makes sense for a lot of people. There is another camp, which claims that left/right should expand/collapse nodes. This is the standard on a lot of operation systems and it does kind of make sense. However in GtkTreeView shift+left/right has been allocated for expanding and collapsing nodes. I've been blocking the idea of making left and right expand and collapse nodes for a very long time, since we really need the arrow keys for moving that focus rectangle. At the beginning of the 2.12 cycle I kind of gave in, since ctrl+left/right was also bound to moving the focus cursor. This basically accompanies ctrl+up/down that moves the focus cursor up/down without changing the selection. And thus left and right now expand and collapse nodes. And guess what, other people now find these new key bindings awkward ;) As examples where this is awkward gconf-editor and tag editors are noted. Now note that both of these are lists, where the usually cited example by the “left and right should expand/collapse” camp are things like nautilus, or any application with a tree and no editable or activable cells. So, as a solution I am currently thinking of the following, to cover both completely different situations and use cases:

• Left and right moves the focus cursor in lists.
• Left and right expands and collapses a node if it is a parent. If a node is not a parent and has editable and/or activable cells, move the focus cursor (this will cover testtreefocus even).

When no action is to be done, left and right could scroll as usual. Does any UI person has other suggestions or opinions? Some background information: #105895 – Please add common keybindings for the TreeView #465516 – Impossible to switch cells with the left and right keys