Community
Participate
Working Groups
When calculating the widths of columns that have a ColumnWeightData with both weight and minimum width, the AbstractColumnLayout appends the minimum width on to the width calculation rather than using it as an actual minimum value. This causes the widths of the columns not to honor their weight settings correctly. Say for instance that you construct a table or tree with two columns, the first with a weight of 1 and a min width of 50, the second with a weight of 1 and a min width of 100. If there are 400 pixels of available space we should see both columns having equal width. The minimums should not come in to play in this instance. Instead the second column is larger than the first. The algorithm in question is located in AbstractColumnLayout#layoutTableTree
*** This bug has been marked as a duplicate of bug 204712 ***
The issue outlined here isn't really related to the columns allowing themselves to be resized to a value smaller than their minimum size, it is more concerned with the initial width the columns receive when they have both a weight and minimum size. If you want to tackle both of the issues at once though, that would be great though! :) If you would like any help with this one let me know and I'll see what I can do Tom.
Accepted, go a head and provide a patch :-)
Created attachment 82966 [details] Test identifying the problem This is a test outlining the problem. I couldn't find the other tests for this layout or I would have included this one among the others.
Created attachment 82967 [details] Patch correcting the problem This is a patch that changes the behavior of the layout to calculate the widths based on weight, but use the minimum if the weighted width falls below the minimum.
released fix to CVS-HEAD >= 20080118 (I modified the patch to giving kudos to you for the work)
verified by because tests are run and passed in I20080205
