I could still see the utility of the method you just added and reverted being in TableViewHeader as well - in case the caller wanted to know how wide to make the column to allow for the header as well. It's not critical though...
On Wed, Aug 26, 2009 at 5:54 PM, Greg Brown <[email protected]> wrote: > Yeah - one could just call into the other. But I'm thinking that this only > belongs in TableView, not TableViewHeader. > > > On Aug 26, 2009, at 5:51 PM, Todd Volkert wrote: > > 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. >>>>> >>>>> >>>> >>>> >>> >
