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.
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] etable/outline
Created attachment 60690 [details] OutlineView
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 make). 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 nbdev@netbeans.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 worse.
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.
Hello, 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 ... Br, David
if there are no more comments i'll integrate the outline/outlineview on thursday morning (may 27th)
done 5ca2a45fd6a1