Supporting a -1 value makes sense, but I think also providing TableView.getPreferredColumnWidth(columnIndex:int):int makes sense, for the cases where the app developer doesn't want to incur the performance penalty of calculating the preferred column width every time the table view is called to layout.
-T On Wed, Aug 26, 2009 at 5:44 PM, Greg Brown <[email protected]> wrote: > After working through the implementation, I remembered that > TableViewHeaders determine their preferred size based entirely on the widths > of the TableView's columns. It doesn't factor its own content in at all > (except for height). > > So, it actually wouldn't be inconsistent to support a -1 value for column > width. In fact, this would increase TableView's consistency with TablePane. > > > > On Aug 26, 2009, at 4:56 PM, Greg Brown wrote: > > We actually already have a number of skin methods in TableView.Skin and >> TableViewHeader.Skin, so adding this would not be a big deal. >> >> On Aug 26, 2009, at 4:53 PM, Todd Volkert wrote: >> >> On the other hand, this would have to be a skin pass-through method, >>>> since >>>> the skin (especially the TableViewHeader skin) may want to apply some >>>> additional padding or spacing around the renderer. So we'd need to add >>>> these >>>> methods to TableView.Skin and TableViewHeader.Skin. >>>> >>> >>> >>> Yep. Given the other skin methods we've added to other classes, I'd >>> think >>> that these methods would make sense. >>> >> >> >
