Setting graphics of a Labeled does not show the Label correctly
Nir Lisker
nlisker at gmail.com
Thu Dec 1 18:47:38 UTC 2022
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.rushforth at 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.hendrikx at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221201/37b8a8c6/attachment-0001.htm>
More information about the openjfx-dev
mailing list