Currently, TreeTableView fully follows sizing
policy of JTable, which leaves computation of
correct preferred sizes on client side.
However, it looks like auto-resize feature of
columns would be used on several places. With
current state, it's not easy to create table which
will ensure that header texts are always visible,
even if bigger fonts and longer localizations are
Here are steps that needs to be done:
1) Contact Siwng team, examine reasons why JTable doesn't support auto
resize at all, find out if something like this is planned.
2) Either leave the problem to the clients (current state) or define
API, something like:
void setEnsureVisibleHeader (int columnIndex, boolean value);
boolean isEnsureVisibleHeader (int columnIndex);
*** Issue 34384 has been marked as a duplicate of this issue. ***
Does this relate also to 33247 ?
Fortunately no, right height of rows in TreeTableView was easy to
implement without any API or client side changes. Width of columns is
Fix for 33247 is already commited into release35.
FWIW, this might be fixable with the same type of hack
(only a hack because JTable should do this itself) we
used for font height:
On the first paint() call, check a boolean flag. If true,
get the current font, calculate the width you need and
call the setter for it (this will trigger a repaint, so
just set the flag to true and return from paint()).
Anyway, a much better solution would be to rewrite
TreeTableView to be a simple JTable and incorporate
such a fix. The way it is
implemented now is pretty bizarre. I've been talking a
bit with Jirka R. about this, because the code would be
very similar to the new property sheet code.
Probably we should wait to see if the Nodes API is being
deprecated in favor of Looks. FWIW I wrote a ListView
replacement over the weekend which simply renders a
Look directly, for my OutlinePanel module, and it is
incredibly fast, lightweight and has *no threading
problems* that I can find yet :-)
So, if we kill Nodes, old Nodes will simply be
wrapped in a Look as a compatibility bridge, but the
explorer views will need to be completely rewritten
(to be much more simple :-).
*** Issue 34105 has been marked as a duplicate of this issue. ***
What does openide.explorer.view.TreeTable.calcRowHeight() row height
autocalculating code? Is not it the fix?
In comments of 34189 it mentioned that this issue
seemed to be fixed - can you confirm about it ?
If it is, are there any additional steps or api
calls that other modules need to use to be able
to use the fix ? (since there were many resize
issues about the jtable column width all over products) ?
Status of this issue, for those with dependent issues:
There are no plans to make any further changes to TreeTableView for
3.6. The existing TreeTable implementation is fragile and has severe
problems, and typically fixing one thing in it breaks something else
(note the 40+ open defects against it - TTV is half my bug count). So
in the interest of not destabilizing anything during the period we
need to be stabilizing 3.6, I strongly advise against making any
changes to it unless it is on fire (throwing exceptions or otherwise
blocking users from getting work done in critical ways).
There is an open task to rewrite TreeTableView from scratch. This may
be done in the promotion-D timeframe, but resources (me) are not
allocated yet to do it - it depends on what other tasks are on the
table, and their priority relative to the importance of rewriting
TreeTableView. I hope it will be possible to do it soon; it depends
what other things I'm asked to work on and/or who else might be
available. I estimate to do it properly (no embedded trees as cell
renderers, no event translation between components, etc.) will take
+/- 1 month.
If there is time, after I have closed all of the issues I have
committed to for 3.6, I can take a look at this problem. But anything
requiring > 1-2 line changes is high-risk and probably won't go into
3.6. I apologize if that's not the answer you were hoping for.
Tim you should cooperate with Tim Lebedkov. He implemented his own
TTV. It can be found under tasklist/core/.../treetable package.
Yes, I am interested in looking at his TreeTable. Anything would be an improvement.
Main question is when my management will say "OK, Tim, you now have a month to
do nothing but fix the tree table."
IMO the whole compound-component approach is wrong - what is really needed to
do this well and scalably is a TableModel which implements tree semantics. Any
solution that still involves event translation between two components is going to have
some of the same problems we have now. Unfortunately, to really do it right is a huge
amount of work, most of it not much fun (tree layout caching, expanded path
management, etc. Some things could be borrowed from, e.g.,
FWIW, I did encounter one TreeTable that is designed more or less this way, in a
defunct Mozilla project called Grendel (MPL should be a pretty compatible license).
So when I get the time to do it, I will look at adapting Tim's solution or that one and
see which looks more promising.