GNOME Bugzilla – Bug 598739
TreeViewColumn incorrectly resizes itself with sizing mode of AUTOSIZE and TreeStore model?
Last modified: 2018-02-10 03:29:47 UTC
Created attachment 145643 [details] Screenshot. I noticed that if you have a tree view with a column in it (with a text renderer in the column) that has its sizing mode set to AUTOSIZE, you use a tree store as the tree view's model, and then: 1) Create a top-level row with a semi-long string in it, but not long enough to cause the tree view column to increase its own width. 2) Create a child row of that top-level row with a shorter string in it. ... then even if the child row's string is shorter than the parent row's string, the tree view column will increase its width. Is this intended? I kind of get why this might be happening but still this functionality seems counterintuitive to me. Attached is a screenshot as well as an example in C.
Created attachment 145644 [details] Example.
*** Bug 355314 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Is this intended? I kind of get why this might be happening but still this > functionality seems counterintuitive to me. Not really. But you are the first one that managed to correctly and briefly describe it and create a small stand-alone test case. Will be looking into this.
Okay, this is not at all trivial to fix. The main culprit here is that requested size is kept for each cell, the requested size for a column is the sum of these for the cells. So we have [indent][image_size][text_size ] if we add another row as child, shorter string: [indent ][image_size][text_size] then tree view will re-use the size of the cell according to the first string, because that is larger. The column size becomes: indent + requested image_size + requested text_size. image_size and text_size are the same as in the first row, but indent increases, resulting in: [indent][image_size][text_size ] [indent ][image_size][text_size ] If I recall correctly, the per-cell size maintenance was also hurting something else. I can't remember what exactly right now. It is clear that when we address the cell sizing/layouting that this has to be addressed as well.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.