the current TreeTable component (and its 'view' counterpart TreeTableView) is very buggy, doesn't support drag and drop,
has poor sorting capabilities and is hard to maintain. there's a new implementation of this component in contrib/ttv
(the authors are Tim Boudreau and David Strupl). i propose introducing the new implementation into netbeans 6.5 and
depracting the old TreeTableView.
the new component - called Outline/OutlineView - is compatible with TreeTableView from the data model point of view so
the transition to the new component is very easy and straightforward. i've already tried replacing TreeTableView in all
debugger windows with the new OutlineView and didn't find any major problems. other moodules currently using
TreeTableView (e.g. find usages, local history etc) would benefit from the new OutlineView as well - better sorting,
quick-search capabilities, drag'n'drop, less bugs.
currently there is a new module o.n.swing.outline which has two components ETable - JTable with extra capabilities,
similar to JTable from JDK1.6 and Outline component which inherits from ETable and provides a 'table with expandable
rows'. openide.explorer then depends on this module and provides OutlineView based on Outline component. i'll attach
sources for both modules later on.
two issues have already been identified:
1. do we want to make ETable and Outline component public API? currently, TreeTable component which TreeTableView is
based on is not public. on the other hand plain Outline/ETable component might be useful for platform developers...
2. rename Outline/OutlineView as the name evokes navigator-like component
Created attachment 60689 [details]
Created attachment 60690 [details]
I'm not attached to "Outline" as the name - I borrowed the name from Apple's Cocoa library (it's what they call a treetable). But it's better than calling it
TreeTable2 or something. "TreeTable" was always a kind of clunky name; on the other hand, Outline is non-obvious unless you either think really hard
about it or are familiar with Cocoa.
I do think the control should be public and available for use outside of NetBeans, or for use without Nodes. In general there needs to be a non-broken
TreeTable implementation, and the one in SwingX is based on the same broken design as ours.
I had some conversations with Scott Violet a couple of years ago about what should be exposed, and he pointed out that since OutlineModel couldn't be
reused for two Outlines at once, it probably ought to be hidden (i.e. you pass in a TreeModel and a RowModel, and an OutlineModel is created, but it is
transparent - the TreeModel + RowModel *can* be reused, but the OutlineModel holds some state for the control (on the other hand, having two JTrees
over the same model is a cute trick that is completely useless in practice, but from an MVC-purist's point of view, Scott was right, and the change is easy to
I know David was worried that some JDK 6 features which duplicate those in ETable would break ETable. Do we know what the story is on that?
> I know David was worried that some JDK 6 features which duplicate those in ETable would break ETable. Do we know what
the story is on that?
it compiles fine under jdk 1.6 and a brief run of a demo application under jdk 1.6 didn't show any problems either
I also think that the implementation shall be independent from Nodes and work outside of NetBeans, too. My personal
opinion is that the best for the entire community would be to unify the efforts and use and enhance SwingX for that purpose.
What I additionally see that a treetable component has to do is:
- be able to give identifiers for the columns (like TableColumnExt in SwingX). These make easier identifying the sorting
or even specifying the column order (helping applications to better save/restore their UI states);
- be able to sort the columns programatically and manually, inclusively the tree column;
- be able to get the sort column's identifier and order;
- get notified when a sorting "gesture" is initiated. This shall be fired when the user clicks on the header of a column
and start sorting; or when the component is programatically sorted or when sorting is reset. Shall be fired
independently from the content of the treetable (or table), so even if the model is empty or none of the rows are
"swapped" (this is not available in the SwingX API today, thus it can be done with some hacks at the moment);
- if a column is sorted, adding a new element should keep the correct sort order.
Basically the SwingX JXTreeTable and related APIs have almost all the things above (except the sort gesture
notification), unfortunately sorting is not working today and the cell renderer and cell editor mechanism seems to be
not finished either (at least compared to the similar implementation in JXTable).
Some nice to have features:
- be able to have more than one sorting column at the same time. This is what Outline has, unfortunately the entire
sorting is buggy (not just breaks the nodes hierarchy in the tree, but even the columns are wrongly sorted). Also it
does not let sorting the tree column.
- some filtering controls (see SwingX for more details).
Finally, sorting was working correctly in the original NetBeans TreeTableView, unfortunately it was not possible to
drive it externally.
So what would be ideal? SwingX look and features (fixed) + sort gesture notification + multiple sorting columns from
Outline + original TTV sorting quality :-)
I wish that it is possible that NetBeans and Swing (thus the entire community) can both benefit together from this. Also
wish that the existing implementations can be adapted to a common solution.
The problem with the SwingX component (JXTreeTable) is that it is based on the same broken design as the NetBeans TreeTableView - based on Scott
Violet's Swing connection article circa 2000. When I owned TreeTableView and started on Outline as a replacement, I asked on a number of mailing lists
and got answers from people about their experiences with their own TreeTable components, and there were howls of pain from everyone who had used
that design (I think the firstname.lastname@example.org archives circa December 2003 will have this discussion). I'd be happy to see Outline *become* the SwingX tree
table, but using it as is just means trading a broken component we are able to fix (read: lots of bandages, dental floss and duct tape) for one broken in
similar ways which we can't fix.
Specific problems with the SwingX design:
- Forwarding events to an offscreen JTree that has no peer is insane. It happens to work, by accident, because of the way BasicLookAndFeel and its
subclasses are designed, but there is no rational reason someone writing a Swing look and feel should write their TreeUI delegate to behave normally if it
receives events when it is not actually onscreen - it just happens to work with the JDK look and feels.
- In many look and feels, the colors and appearance of a JTree are different when it is focused or not focused, and convincing an offscreen component that
it has focus so it will paint correctly on all look and feels is not possible (right click a selected item in a tree table view in NB and notice how the
background of the text of the item becomes gray while the rest of the row is in blue - fixing this bug on the look and feels where it appears will break it
on other look and feels)
- Using a JTree as a cell renderer is horrendously inefficient by default, and the optimizations are non-obvious evil hacks (I sped up TTV rendering on
Windows by 3x once by not changing the bounds of the JTree as it is rendered, so it doesn't try to lay itself out again for each cell in the tree, by
translating the graphics context and disabling its ability to have its bounds changed in the rendering process)
Certainly there are features in JXTreeTable that it would be nice to have. But using JXTreeTable would just continue the existing mess and likely make it
since there are not that many comments as i expected i'm switching to fast track api review now. i propose to add the
outline component and outlineview to the main repository in the current form as attached to this issue. the new api will
be labeled 'devel' for the moment and finalized before 6.5 release. there should be some room to add some enhancements
as sbz1977 suggests in milestone 2.
tim, david - please check the attached sources as i had to make some minor api changes in your code.
I have briefly checked the views (OutlineView and TableView) and it seems ok except for the license - I guess you will
have to change the license for all the files ...
if there are no more comments i'll integrate the outline/outlineview on thursday morning (may 27th)