If the width limits were preferred would the width also need to be called preferred?
Project wide consistency is not my domain so I am happy to go with whatever you guys decide :-) On Tue, 6 Oct 2009 05:42:58 am Greg Brown wrote: > I think it actually may be OK to skip the bounds checking in this case > as well as in Component: > > 1) In Component, we're currently validating an explicitly set > preferred dimension against its limits. However, there is no real need > to do this, because getPreferredSize() does it automatically: a > preferred dimension that falls outside the range, whether set > explicitly or calculated, will never be returned by getPreferredSize(). > > 2) A TableView column's max. and min. width values could almost be > considered "preferred width limits". Maybe we should just call them > that, since it would resolve the ambiguity, and would be more > consistent with Component. > > Thoughts? > > On Oct 5, 2009, at 8:35 AM, Greg Brown wrote: > >> * We should probably throw if the column is fixed-width and outside > >> the > >> limits (both in setWidth() and in setWidthLimits()). This check > >> obviously > >> wouldn't apply to relative and default width columns. > > > > I agree that we should throw in setWidth(), but I'm not sure we can > > do that in setWidthLimits(). The default value of width is 0, so > > this WTKX declaration would always throw: > > > > <TableView.Column minimumWidth="10"/> > > > > I'm not sure what the right solution is, but I'm thinking maybe we > > should simply adjust the width value. What other options are there? > > Whatever we decide, we should also modify > > Component#setPreferredWidthLimits() and setPreferredHeightLimits() > > to do the same. > > > > My only other comment is minor: we should probably also provide > > getWidthLimits():Limits and setWidthLimits(Limits):void methods. > > > > Otherwise, looks great. Thanks! > > > > G
