Re: treeview and column indices

[muppet <scott asofyet org>]

zentara said:
> Hi, I've been trying to get the complex
> TreeView model into my head, and ran into
> a little roadblock, which I can't seem to find the answer to.
>
> The script below is from the novell-study-guide examples,
> modified to have some child indices and a second column.
>
> My problem comes when editing column 1. In the original script's
> callback &cell_edited, he derived the column from the $cell.
>
> my $column = $cell->get_data('column');
>
> This works for column 0 and it's descendants, but when I click
> on column 1, it always returns 0.
>
> So I had to resort to adding a data-rider to the cellrenderer, to
> mark it as column 0 or column 1.
>
> $renderer1->{ 'column' } = 1;
>
> So is this the way to go in this type of situation, or am
> I missing the way to get the right indices when I click on
> column 1 ?

CellRenderers are at the bottom of the TreeView dependency stack, and  
don't
know about the TreeViewColumns that pull them together.   
TreeViewColumns don't
necessarily know their position within the TreeView.  So, no, there  
is no
built-in way to associate a column with a CellRenderer.

But you don't need a way to associate the TreeViewColumn index with the
CellRenderer, because the TreeViewColumn index has nothing to do with  
the
index of the TreeModel column from which the CellRenderer gets its data!

The most important thing to remember is that there are two similar  
things with
similar names but which are completely unrelated, except for the fact  
that
most people tend to synchronize them for simplicity.

    TreeViewColumns are unrelated to TreeModel columns.

In fact, you don't want to hard-code TreeViewColumn indices anywhere  
into your
view-handling code after setup, because there are various pieces of  
UI goo
that can reorder TreeViewColumns!  If your code is written correctly,  
you will
require no changes.

    TreeViewColumns are unrelated to TreeModel columns.

TreeViewColumn X can have a CellRenderer which gets the value of  
property "a"
from column n of the model, the value of property "b" from column "n 
+1" of the
model, and the value of propery "c" from column 0 of the model.
TreeViewColumn X can be reordered to be X-1, but the indices of the
CellRenderer's source TreeModel columns will not change.

    TreeViewColumns are unrelated to TreeModel columns.

So, you, as a developer, are left to use any means you deem  
appropriate to
communicate the proper source column index to the "cell-edited"  
callback.  In
C, a very common way to do this is by attaching the index via the  
GObject data
hash, with g_object_set_data().  In perl, the easiest way to do this  
is to set
something in the instance hash, as you have done, "$cell->{column} =
$number;".

> The $cell being passed to the callback is different for
> column 0 and column 1, so why would
> my $column = $cell->get_data('column');
> return 0 for column1 ?

Because nowhere in your code do you call "$cell->set_data('column',  
$value);" to put a
number into that field.  It therefore comes back as NULL from
g_object_get_data().  However, since the GObject data hash doesn't  
allow us to
attach type information to the value, we treat those values as plain  
integers
(it even says this in the Glib::Object manpage, i swear i am not  
making this
up ;-), so that NULL is seen in perl as a 0.

In general, you don't want to use ->get_data() or ->set_data() for  
anything.




--
muppet <scott at asofyet dot org>