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.
