Re: Bugs in TreeTableViewSkin. resizeColumnToFitContent() - labels always ellipsized
As far as I can recall there are no bug reports on this issue. Please do
file them so that TreeTableView can be improved. Thanks.
-- Jonathan
On 13/01/17 10:00 PM, Daniel Glöckner wrote:
Hi,
we recently came across some limitations (you might call them bugs) in the tree
table implementation.
We were unhappy with the default behavior of the tree table implementation.
Some columns were always ellipsized and the user would need to manually resize
the column to fit the contests.
After analysis it turned out that there are various bugs inTreeTableViewSkin.
resizeColumnToFitContent(). We subclassed inTreeTableViewSkin and fixed that
method (fortunately it's protected ;)).
I'l explain the bugs below. Is anyone aware of an existing bug report for this
issue?
If we have a tree table where the first column contains long text (>80px) and
is auto-resizable, then TreeTableViewSkin#resizeColumnToFitContent calculates the
preferred width incorrectly and the label is ellipsized (because during layout
phase, the calculations are performed in other way). We've found two reasons for
that:
1. This method creates mocked cell and row. However for row:
* TreeTableRow implementation is used and any custom factories are ignored
* Cell is not added to row children. As a result if we have some padding in a
cell, based on a row class (e.g..row-class > .cell { -fx-padding: 20px }), then
this padding won't be considered while resizeColumnToFitContent
2. When width is calculated for a cell, there is a special method
TreeTableCellSkin#leftLabelPadding, which makes offset for a label based on
indentation and disclosure node size. However, at the time of calling
resizeColumnToFitContent, disclosure size is considered 0 (it's stored in
TableRowSkinBase#maxDisclosureWidthMap, which is filled only when row is
layouting).
One more note - during preferred width calculation, only expanded nodes are
considered. This could be expected behaviour, however in some cases it makes
sense to have it configurable and make the column suit even collapsed rows
I'm keen to hear feedback from the community. We can also share our "fixed"
skin which is a subclass of inTreeTableViewSkin.
Kind regards,
Daniel
Bugs in TreeTableViewSkin. resizeColumnToFitContent() - labels always ellipsized
Hi,
we recently came across some limitations (you might call them bugs) in the tree
table implementation.
We were unhappy with the default behavior of the tree table implementation.
Some columns were always ellipsized and the user would need to manually resize
the column to fit the contests.
After analysis it turned out that there are various bugs inTreeTableViewSkin.
resizeColumnToFitContent(). We subclassed inTreeTableViewSkin and fixed that
method (fortunately it's protected ;)).
I'l explain the bugs below. Is anyone aware of an existing bug report for this
issue?
If we have a tree table where the first column contains long text (>80px) and
is auto-resizable, then TreeTableViewSkin#resizeColumnToFitContent calculates
the preferred width incorrectly and the label is ellipsized (because during
layout phase, the calculations are performed in other way). We've found two
reasons for that:
1. This method creates mocked cell and row. However for row:
* TreeTableRow implementation is used and any custom factories are ignored
* Cell is not added to row children. As a result if we have some padding in a
cell, based on a row class (e.g..row-class > .cell { -fx-padding: 20px }), then
this padding won't be considered while resizeColumnToFitContent
2. When width is calculated for a cell, there is a special method
TreeTableCellSkin#leftLabelPadding, which makes offset for a label based on
indentation and disclosure node size. However, at the time of calling
resizeColumnToFitContent, disclosure size is considered 0 (it's stored in
TableRowSkinBase#maxDisclosureWidthMap, which is filled only when row is
layouting).
One more note - during preferred width calculation, only expanded nodes are
considered. This could be expected behaviour, however in some cases it makes
sense to have it configurable and make the column suit even collapsed rows
I'm keen to hear feedback from the community. We can also share our "fixed"
skin which is a subclass of inTreeTableViewSkin.
Kind regards,
Daniel
