GNOME Bugzilla – Bug 147867
fix the size allocation logic in GtkTreeView / GtkTreeViewColumn
Last modified: 2013-10-16 02:07:12 UTC
Things are quite broken currently, e.g. the cell_area is not necessarily contained within the background_area, and if you set horizontal-separator to larger values, cell get moved out of the column. Also the editable widgets are not placed exactly over the cells they are editing. Also, jrb reports that the cell_areas are wrong for all shrunk cells. We have come up with a scheme for how things should be done, see the attached image. After fixing the size allocation to conform to it, the image should be moved into docs and be referred to from widget-geometry.txt (unless someone wants to go to the trouble of converting it to ASCII art)
Created attachment 29638 [details] cell geometry
I committed a partial fix for this, and added that excellent picture to docs/tree-column-sizing.png. To really fix this bug, I think we're going to have to do a minor audit of gtktreeview{,column}.c. In particular: * check all the (indirect) callers of gtk_tree_view_column_cell_process_action, and make sure that they all pass in a consistent cell_area/background area * Have the background area be essentially cell_area + vertical-separator, and have already subtracted out things like the expander and the horizontal-separator. It makes the background area a little bit useless, but that's okay -- it was always dubious. * Double check the image. In particular, I think that we aren't calculating extra_space correctly.
We have a problem that I think is related. If a column of text is right aligned and the column size is reduced, text starts getting clipped on all columns as soon as the longest string won't fit, rather than having every cell right align to the visible area. jrb, is this what you meant when you said that the cell_areas are wrong for all shrunk cells? What's happening is that the cell width given to cell renderers in GTK+ is the maximum size over all rows in that column. This means that the x offset will be calculated assuming an edge which is not visible. I think it would make more sense if cell_area represented the visible area. Also see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=76062
Right now, cell_area is the actual cell_area plus the focus_line_width, which is different from the cell geometry image, but (I think) the same as Jonathan was saying in his comment. background_area is basically cell_area plus separator (horizontal and vertical).
See gtk+/tests/testcellrenderertext - it may be useful to test this kind of stuff.
I did some more fixage in this area last week. I don't think we can change the background_area behaviour at this point. The image is pretty much right as far I'm concerned. A little audit of _cell_process_action() might be in place, but I think I looked at most cases already while debugging last week (and a few months back).
I assume this is probably fixed by now? Can someone confirm if this bug can be closed?
if it is not fixed, everybody has gotten used to the remaining issues now...