Re: More on embedding combo models in a treestore

[muppet <scott asofyet org>]

(cc'ing gtk-devel-list to see if anybody can confirm whether this is  
a bug in gtk+ or behaving as designed.)

On Jul 8, 2005, at 12:22 AM, Daniel Kasak wrote:

> If I edit a cell with a combo and then click into another row,  
> however, things go screwy. The problem seems to be that by clicking  
> in another row, I'm 'activating' it *before* my code catches the  
> edit and figures out what to put back into the cell. ie when I get  
> hold of the combo's model, I'm actually getting the model of the  
> combo in the *new* row that I just clicked in, and not the model of  
> the combo in the *current* (from my point of view anyway ) row.

I can confirm this with the little test program i posted earlier  
( http://mail.gnome.org/archives/gtk-perl-list/2005-July/ 
msg00065.html ), by adding these lines to the "edited" callback:

    my ($combo_model) = $model->get ($model->get_iter_from_string  
($text_path), MODEL_COLUMN);
    warn "NOT THE SAME\n" if $combo_model != $cell->get ('model');

then clicking in a row, clicking again in that row to edit it,  
choosing something else from the menu, then clicking in another row  
to commit the edit instead of hitting the enter key.


By the way, 'activate' has a special meaning; what you were doing is  
*selecting* another row.  You "activate" a row by double-clicking it  
or hitting enter when the cursor is in it.



> The strange thing is that while I get hold of the wrong model, the  
> correct row ( ie the one I edited ) is updated.
>
> Here's the code in question:
>
> sub process_text_editing {
>
>     my ( $self, $renderer, $text_path, $new_text ) = @_;
...
>         my $combo_model = $renderer->get("model");

I think this is an artifact of the way cell renderers are used to  
draw the tree.  Quite possibly a bug, as well, but let's have a look  
before deciding that.

The "edited" callback is given the renderer that emitted the signal,  
and the TreePath of the row that was edited.  So far, so good.

But the renderer is used to draw every row in the column, not just  
"this" row.  When the TreeViewColumn needs to paint a cell, it uses  
the attributes assigned to that cell renderer to set the renderer's  
object properties *for the row about to be drawn*.

My hypothesis here is that the edited signal is emitted on the  
renderer for row n, immediately after the renderer was used to draw  
row m, and the object properties have not been reset for row n.   
Thus, you see the object properties for row m (that is, the wrong  
model).

I'm assuming you have the combo models stored in a spare column of  
the main tree model (as previously discussed); instead of getting the  
combo model from the renderer, try getting it from the tree model  
row, like so:

    my $path = Gtk2::TreePath->new_from_string ($text_path);
    my $model = $self->{treeview}->get_model;
    my $iter = $model->get_iter ($path);
    my $combo_model = $model->get ($iter, COMBO_MODEL_COLUMN);


If this works, then it's a good bet my hypothesis is correct.  This  
smells a bit like a bug, and if nothing else violates the principle  
of least surprise, but it's up to the gtk+ developers to say whether  
it's really wrong.

The cell doesn't know about the model and therefore can't actually  
set this stuff up for itself without calling back to the  
treeviewcolumn, so i'm not sure how you'd fix this.

--
Walk softly, and carry a BFG-9000.
  -- unknown