If no ExpandCollapseListener set, don't put handles on nodes with no children.

[nishihatapalmer]

If the code is not dynamically responding to expand/collapse events and a node has no children, then there is no point in putting an expand / collapse handle on it.

Add logic to only add these when a listener exists that might handle it.

Other thoughts - you may have a listener for some reason, but you aren't dynamically updating the tree. Maybe have yet another setting to explicitly set whether nodes with no children have handles?

Have to think about whether this makes sense - would we automatically put handles on as soon as a listener is set? Have update listeners vs. non update listeners? Could get into situation where you set a listener and you get handles, when you already said you don't want them.

[nishihatapalmer]

• Nodes that don't allow children don't need handles.
• The question is whether nodes that allow children, but have a current child count of zero should have them.
• If a child of a visible parent is inserted, then it would need handles.
• If there are no listeners defined, then nodes cannot be dynamically added on expand, so no need for handles.

So, only need to decide what to do when a listener is set. Could state whether it is read-only or potentially modifies tree. If it can modify tree, then we need handles. If it's a read only listener, we don't. Bug prone maybe.

[nishihatapalmer]

What if we want a tree expanded and don't want the user to be able to expand or collapse any further nodes?

Control over which nodes get handles seems to be more general than just the dynamic tree use-case.

[nishihatapalmer]

So we'd have a HandleStrategy or HandlePolicy object that controls which nodes get handles and what the conditions for that are.

[nishihatapalmer]

The TreeCellRenderer renders the handles, but doesn't control if they can expand or collapse.

Should this be in sync, so the table model should be able to determine if a node can expand or collapse, and then the renderer should reflect this when rendering the handles?

Would we want nodes that have no expand or collapse handles but which can still be expanded or collapsed through a key press or tree click? I can see we might want to be able to programmatically collapse or expand nodes but not show visible handles (to respond to user input directly).

[nishihatapalmer]

So handles are all about visual indication to users that they can control expand or collapse through user input directly.

But should not prevent programmatic expand or collapse.