Re: JTreeTable

On Wed, 2003-01-29 at 07:56, Tim Lebedkov wrote:
> Hello,
> 
> I spent yesterday some hours and replaced TreeTableView with JTreeTable from the Swing Connection
> (http://java.sun.com/products/jfc/tsc/articles/treetable2/index.html). 
> 
> There are some advantages by using this component:
> + it allows you to scroll the whole component horizontally. Not just the first column.
> + it allows you to rearrange all the columns (the first too)
> + it is model-based (!). We will be able to write a model for our Tasks. It will help us reduce memory consumption and 
>   improve performance as we only need to maintain one tree of objects and a model (currently we have at least 4 levels of 
>   objects: Tasks, TaskNodes, FilteredTaskNodes, VisualizerNodes and hundreds (OK, maybe dozens) of listeners).
> + we will have full control over the component and will be able to resolve some bugs
> 
> There are also some things now that are not implemented:
> - sorting
> - turning columns off/on
> 
> What do you think about it?
> 
> I could implement as the first step a component based on JTreeTable that behaves just like TreeTableView and uses NodeTableModel.
> As the second step models for our views could be implemented. I wrote an issue against the openide module 
> (http://www.netbeans.org/issues/show_bug.cgi?id=30447 Swing compatible TreeTableView) and asked for a model-based TreeTable.

I think approaching openide and getting the TreeTableView changes is the
best approach. The TreeTableView is used in many other places (debugger,
module manager, etc.) so it would be bad to fix this locally, not
globally.

We still need to Node APIs for getting property sheets etc. to work
correctly.  It would however be nice to be able to create the nodes
lazily (much like the way the table model allows you to only provide
values for those rows that are visible in the table). So, instead of
having to create all the children of the root node right away, it
could ask for children in chunks.    If we're only creating nodes for
the visible rows, we're not going to consume very many resources at
all. And it would allow most of the APIs to stay the same. The Children
API would have to be changed in openide to allow dynamic node requests
however.

I think it would be a good idea to make your proposal to nbdev,
since it involves some API changes, and affects multiple modules.

-- Tor