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, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
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 <kris@gtk.org> * 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.