This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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 used.
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 ?
Hi Ken, Fortunately no, right height of rows in TreeTableView was easy to implement without any API or client side changes. Width of columns is another story. 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) ? ken.frank@sun.com 09/08/2003
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., FixedHeightLayoutCache). 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.