Yeah - it's just inconsistent. That would be the *only* way you could
do that, and you'd always have to do it manually. Just seems odd.
On Aug 26, 2009, at 6:10 PM, Todd Volkert wrote:
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.
