GNOME Bugzilla – Bug 309221
treeview duplicates last column sometimes
Last modified: 2011-02-04 16:18:46 UTC
Please describe the problem:
there have been reports of problems with treeviews using 2.7,
Steps to reproduce:
Does this happen every time?
The observed behaviour is caused by evolution, grip and other apps reusing a
single cell renderer for multiple columns. This probably never worked reliably,
since there are tree view functions which assume that it is possible to set the
correct data on all cells simultaneously (e.g.
_gtk_tree_view_column_count_special_cells), but it probably worked more or less
before the following commit:
2005-06-18 Kristian Rietveld <email@example.com>
* gtk/gtktreeview.c (gtk_tree_view_bin_expose): undo merging
of the separate loop setting cell data with cell drawing loop
(introduced in revision 1.280), since this breaks focus handling
wrt special cells.
I think our best bet is to officially forbid reusing cell renderers for multiple
columns. Its unfortunate that this breaks apps.
We should probably add the set_cell_data calls back in the second loop in
bin_expose, to make it work as well as it did before, in addition to the warning.
Yes, we should forbid reusing cell renderers for multiple columns. It *should*
be possible to set correct data on all cells simultaneously, without that we can
never have correct measurements of the width/height of a row and the focus code
won't work correctly either.
I am against moving _set_cell_data back in the second loop in _bin_expose, it
was moved there by accident by somebody when optimizing something (see rev
1.280), which broke the focus code.
Kris, I'm not proposing to _move_ it back.
Keep the first loop, and add the set_cell_data calls to the second loop.
Yes, they will be redundant if we don't have reused cell renderers, but
otherwise gtk+ 2.8 will break many tree view users, e.g. evolution, grip,
probably others. Thinking about it, if we add a way to detect reused cell
renderers with the aim of emitting a warning, we can probably use that
information to avoid the redundant set_cell_data calls in the absence of
resued cell renderers...
Oooh, sorry, I misread your first comment then. This sounds like the way to go, if people agree during the
meeting I will fix it this night.
Committed the simple fix (just adding back the calls to _set_cell_data). Can
optimize it later on when needed.