Michael's idea could solve the problem if it's about more than just traversing, it needs to set rules for allowing a node to serve only 1 logical role (or 1 role type, like clip and graphic?) at the same time. In any case, these rules need to be decided upon before starting to work on anything. I can do a quick fix for now that can be reverted later if needed. From what I gather, I will need to add a graphicsParent field like clipParent does.
On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker <nlis...@gmail.com> wrote: > By the way, these issues are caused by this inconsistent behavior (they > are probably duplicates): > > https://bugs.openjdk.org/browse/JDK-8209017 > https://bugs.openjdk.org/browse/JDK-8190331 > > The graphic of the checkbox of a CheckBoxTreeItem is not set correctly on > the new CheckBox that is provided with the cell when virtual flow switches > it. It might happen with other controls that use virtual flow. > > On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > >> This seems related, but somewhat tangential. A Control's "graphic" isn't >> a child node, just like a Shape's "clip" isn't a child node. >> >> Creating a separate "document graph" (or "logical graph") sounds like an >> interesting idea, but it would bring its own set of challenges. And it >> wouldn't directly solve this case anyway. >> >> -- Kevin >> >> >> On 12/1/2022 9:42 AM, Michael Strauß wrote: >> > There's a larger picture here: from a user perspective, there's a >> > difference between the scene graph and the "document graph". >> > The document graph is what users actually work with, for example by >> > setting the `Labeled.graphic` property. In some cases, document nodes >> > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to >> > mind). >> > The document graph is later inflated into a scene graph of unknown >> > structure (because skins are mostly black boxes with regards to their >> > internal structure). >> > >> > I've proposed an enhancement that would make the document graph a >> > first-class citizen: >> > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html >> > >> > With this in place, we could simply disallow the same node appearing >> > multiple times in the document graph, which would not only solve the >> > problem for `Labeled`, but for all controls with a similar problem. >> > >> > >> > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx <john.hendr...@gmail.com> >> wrote: >> >> The mechanism does seem like it is a bit poorly designed, as it is >> easy to create inconsistencies. >> >> >> >> Luckily it seems that you can't remove a graphic yourself from a >> Control (getChildren is protected). >> >> >> >> I don't think there is an easy solution though... >> >> >> >> I think that once you set a graphic on a Labeled, you need to somehow >> mark it as "in use". Normally you could just check parent != null for >> this, but it is trickier than that. The Skin ultimately determines if it >> adds the graphic as child, which may be delayed or may even be disabled >> (content display property is set to showing TEXT only). >> >> >> >> Perhaps Skins should always add the graphic and just hide it (visible >> false, managed false), but that's going to be hard to enforce. >> >> >> >> Marking the graphic as "in use" could be done with: >> >> >> >> - a property in `getProperties` >> >> - a new "owner" or "ownedBy" property >> >> - allowing "parent" to be set without adding it to children (probably >> going to mess up stuff) >> >> >> >> --John >> >>
