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.

Bug 34379 - [TTV] Provide auto-resize support of columns
Summary: [TTV] Provide auto-resize support of columns
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Outline&TreeTable (show other bugs)
Version: 3.x
Hardware: PC All
: P3 blocker (vote)
Assignee: Martin Entlicher
Keywords: API, I18N
: 34105 34384 (view as bug list)
Depends on:
Blocks: 33246 34188 34189 34190
  Show dependency tree
Reported: 2003-06-13 13:49 UTC by David Simonek
Modified: 2010-10-07 11:33 UTC (History)
4 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description David Simonek 2003-06-13 13:49:45 UTC
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
Comment 1 David Simonek 2003-06-13 13:56:17 UTC
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);
Comment 2 Petr Hrebejk 2003-06-13 14:57:22 UTC
*** Issue 34384 has been marked as a duplicate of this issue. ***
Comment 3 Ken Frank 2003-06-13 16:34:36 UTC
Does this relate also to 33247 ?
Comment 4 David Simonek 2003-06-13 17:54:35 UTC
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.
Comment 5 _ tboudreau 2003-06-16 10:45:40 UTC
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 :-).
Comment 6 Marian Mirilovic 2003-07-22 10:19:36 UTC
*** Issue 34105 has been marked as a duplicate of this issue. ***
Comment 7 _ pkuzel 2003-09-05 16:33:34 UTC
What does openide.explorer.view.TreeTable.calcRowHeight() row height
autocalculating code? Is not it the fix?
Comment 8 Ken Frank 2003-09-08 17:07:36 UTC
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) ?
Comment 9 _ tboudreau 2004-01-16 18:19:26 UTC
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.
Comment 10 _ pkuzel 2004-01-19 12:54:41 UTC
Tim you should cooperate with Tim Lebedkov. He implemented his own
TTV. It can be found under tasklist/core/.../treetable package.
Comment 11 _ tboudreau 2004-01-19 15:41:25 UTC
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.