GtkTreeView changes

[Benjamin Otte <otte gnome org>]

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