Hey Kris, sorry for the late mail, I wanted to get to it earlier, but I forgot. I blame Matthias wanting to get a release out. :)
In case you didn't notice, I did some refactoring in the treeview code and pushed it to master. It's mainly meant for the accessibility implementation. I'll continue doing that for a bit, until the treeview a11y implementation is not a disaster anymore. If you don't agree with any of it, poke me. Highlevel overview of what I've done: 1) Make GtkRBTree track the node number Instead of parity, we now have a total_count, which is basically like parity, just without modulo 2. It is used via gtk_rbtree_find_index() by the a11y code to be able to index rows by number. 2) Make GtkRBNode pointers not reference different nodes over time The reordering and node removal code used to swap the data from one node to another. I fixed that. Now a Tree/Node tuple can be used instead of a GtkTreeRowReference. I'm using these instead of GtkTreeRowReferences in the accessibilty code to have a stable mapping from accessibles to rows. 3) Add a bunch of convenience wrappers/refactors to make code more understandable Basically, I moved GtkRBTree closer to something that could be exposed as a public API, or at least as a semi-public API internally. The rbtree code is actually quite powerful (we could use it to flatten trees to lists in various places, also it might be interesting to implement TreeModelFilter with it, I might want to use it to replace the textview's btree implementation) and might allow a bunch of cool things. I almost convinced Ryan to pull it into glib already. ;) 4) Move treeview a11y from signals to direct function calls Instead of signal handlers that have to work with what is available, I added direct function calls into the a11y code. This allows better control about what information we send to the treeview. And we can actually send private data types without having to expose it to the public API. The treeview is the first widget where I'm doing that excessively, the other a11y widgets should ideally follow. Not sure how much will still follow, but my ultimate benchmark is still way too slow (I time nautilus starting up in list view and close it when the "Loading..." button disappears, so take the numbers with a grain of salt). The numbers are accessibility disabled vs LD_PRELOADing atk-bridge, no actual a11y tools were running. /usr/bin => 12s vs 53s $HOME (4200 files) => 24s vs 63s Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list