Content Graph

[John Hendrikx]

On 18/04/2023 19:14, Michael Strauß wrote:
> Here's a draft PR: https://github.com/openjdk/jfx/pull/1096
>
> There are some API changes compared to my last email, the most notable
> being that the content graph can now contain arbitrary objects. This
> allows the content graph to directly contain a ListView's item list,
> or a Labeled's text.

I've looked it over a bit. Would it be needed to have wrappers around 
some parts of the content graph now that it supports arbitrary objects?

ie. instead of:

     MenuItem
         String
         Rectangle

with wrappers:

     MenuItem
         Label
              String
         Graphic
              Rectangle

The reason I ask is I wonder if the type itself will always be 
sufficient to distinguish the various parts a control adds to the 
content graph.  A ListView's items for example could be arbitrary 
objects; if ListView contributed anything other than its items, it would 
be hard to pick it out.

Or consider a control that for some reason has two texts; I have some 
reusable controls that display an image, a text on top (title) and a 
text at the bottom (subtitle).  These are all labels:

      FancyControl
           String (Label with text only)
           String (Label with text only)
           Image (Label with graphic only)


>
>> Would the returned list here be read only?
> The content graph API is read-only, as its state depends entirely on
> the properties of the participating controls.
Okay, my confusion stems from that there are ReadOnly interfaces for 
properties, but apparently not for ObservableList.  Read only seems good 
to me.
>
>> For a lot of controls I think the content nodes will be fixed
>> (SplitPane, Label, Button), but for others like MenuButton or containers
>> these need to be modified. Does it make sense to use a similar model
>> here that is used for properties? Some controls would still need to be
>> able to modify the list directly, in which case subclasses could go that
>> route as well, circumventing these protections.
> I'm not entirely sure if I understand the problem. For example, the
> content model of Pane corresponds exactly to its children list. If a
> subclass of Pane needs to add something that is not a child, for
> example a "text" or "graphic", it simply adds its own content model in
> the subclass. The combined content model of the control will then
> consist of the entire children list of Pane, as well as the custom
> properties that the subclass added.
>
> In this case, the subclass will not be able to change the fact that
> Pane added its children to the content model. That is by design, as a
> subclass of Pane is still a Pane, after all.

I see that you went a different route here, without using an overridable 
`buildContentModel` (subclasses could not call `super` and in that way 
influence what the parent has as content model).

I guess what is happening is that there are multiple ObservableLists 
that are being concatenated; each individual list is under control of a 
single class, and a subclass can't access the list of its superclass in 
any way.

--John