CheckBoxTreeItem behavior

[Nir Lisker]

I think that even if a node is set to indeterminate programmatically, its
parents should be updated at the very least (unless it's set to be
independent). Not updating the children seems reasonable.

On Fri, Nov 18, 2022 at 11:12 AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

>
> On 18/11/2022 00:10, Nir Lisker wrote:
> > Hi,
> >
> > I have been working on fixing some issues with the behavior
> > of CheckBoxTreeItem. I stumbled across this situation:
> >
> > When a parent is de/selected, all of its children are set to the same
> > state. However, a CheckBoxTreeItem can be set to indeterminate
> > programmatically (the control itself does not allow indeterminate).
> > Should all children also be set to an indeterminate state? If so, this
> > will put the tree at an "invalid" state where leaf nodes can be
> > indeterminate as well. OTOH, if not, then we are again at an invalid
> > state if all children have the same state, but the parent doesn't.
>
> I think the indeterminate state is best left up completely to the owner
> of the control. You may need information that is not part of the tree to
> actually determine if something is indeterminate or not.  A tree may be
> filtered, or a tree may represent only "nodes" while "leaves" are
> displayed in a 2nd control as a list.  This means that in theory, parent
> nodes could be indeterminate even if all its children are in the same
> state (checked/unchecked) due to filtering, and leaf nodes could be
> indeterminate if they represent a directory while the file selection is
> displayed in a separate control.  In Backup software, a directory may be
> partially selected if it has a filter associated with it (like *.java)
> even if that directory is empty or has only Java files currently...
>
> Some UI's will even allow you to click on an indeterminate parent node
> to check it (checking all children), click again to uncheck it
> (unchecked all children), and click a 3rd time to put it back to an
> indeterminate state (restoring all children to the state they had before
> the first click).
>
> --John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221118/6c4c52e6/attachment-0001.htm>