Setting graphics of a Labeled does not show the Label correctly

[Nir Lisker]

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/7e60983f/attachment.htm>