Setting graphics of a Labeled does not show the Label correctly
John Hendrikx
john.hendrikx at gmail.com
Thu Dec 1 21:41:00 UTC 2022
Adding another field doesn't seem ideal, would it be possible to
generalize the clipParent field to function for both (the ownedBy or
owner field that I suggested earlier)?
--John
On 01/12/2022 20:26, Nir Lisker wrote:
> 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 <nlisker at 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.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/54b7c5b7/attachment-0001.htm>
More information about the openjfx-dev
mailing list