Re: JTreeTable II

Tim Lebedkov wrote:
> Hallo Tor,
> 
> one more time about JTreeTable from the Swing connection
> (http://java.sun.com/products/jfc/tsc/articles/treetable2/index.html)
> 
> I'm tired of bugs and limitations in TreeTableView and I want to
> rewrite the tasklist core module to use JTreeTable. It would be a great
> improvement.
> 
> Common problems with TreeTableView:
> -----------------------------------
> 29724 [email protected]@netbeans.orgSTARcurreCategory nodes 
> reexpand when they feel like it
> 27670 
> [email protected]@netbeans.orgNEWcurreEditing 
> tasks does not cause re-evaluation of filter
> Rearranging of the first column is impossible
> One-click-boolean-editor is impossible (2 Clicks are necessary)
> Hiding first column is impossible
> PropertyEditors cannot draw the value in a whole cell (a border prevents it)
> Impossible to compose a complicated renderer from different UI elements
> There is no focus indication (blue box) on the name column so it looks 
> like focus is in lala land. #31456
> No cells are editable by the keyboard. I would expect being able to 
> press the space bar on a cell to be able to edit it like i can in the 
> property sheet. #31456
> No control over the popup menu over a free space in the view
> Slow with more than 1000 rows.
> Same property editor is used for the table cells and in the properties view
> Errors showing selected cells
> missing getProperties() method
> .....
> 
> --Tim


Yes, but my opinion is still the same as when you made the
same suggestion a while ago.
http://tasklist.netbeans.org/servlets/ReadMsg?msgId=455829&listName=dev

You really want node integration so you can view/edit properties
of tasks that are not shown in the treetable (for example, for
usertasks, I only want to see the summary and the priority in
the table, but in the property sheet I want to be able to view
"Last Edited", edit "Category", etc.)

If you're going to have a treetable implementation which views
nodes, this really ought to be the TreeTable in openide.
Why? Not only to avoid code duplication, but so that all uses
of treetable are fixed (the debugger is another heavy client
of the treetable, and from questions on openide-dev I gather
than third party modules built on top of NetBeans also uses it.)
And if we use some custom solution, we'll have to have our own custom
cell renderers for all the different types of properties etc.

However, as you point out in your list above, the openide 
treetable has lots of problems. 

That's why it's going to be rewritten for 4.0. I have CC'ed Jiri Rechtacek
in case he can provide additional details or priorities for this (or
dates?)

I'm sure help in rewriting the treetable would be extremely appreciated!!!

There's a tracking (umbrella) issue for this:
http://tasklist.netbeans.org/issues/show_bug.cgi?id=33281
Improve TreeTableView

As you can see, it depends on these issues which are all related (and
which are motivating the rewrite):
19266 22822 22996 22998 24892 24893 27696 28561 28962 29031 29534 29612 29717 29855 30539 31016 31501 31621 32567 33186 34169 34170 34172 34173 34175 34177 34178 34181 34182 34184 34185

I have also CC'ed Jesse Glick, since I talked to him at JavaOne
and he mentioned something about a Node rewrite; perhaps going
away from a direct node based approach has advantages and will
fit in with the future architecture.

(If you want to go ahead with the swing-treetable rewrite anyway, I think
you should use a branch first so we can compare and contrast the
two approaches before fully committing.)

-- Tor