Re: More on embedding combo models in a treestore

(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 ( 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]