I haven't waded into this discussion yet, but now that it's settling
down a bit, I will offer a couple very brief thoughts.
I am unconvinced that a content graph should be part of the JavaFX core.
I can see how it might be useful to some apps, but it would be a large
change with fairly signifi
Hi Michael,
My current understanding is that yes, FX differs from let's say Swing in that
certain things are not even Nodes (MenuItem, Window, etc.), but once the
initial shock passes, one could certainly write code that constructs the
logical structure using Node.getChildrenUnmodifiable().
Ad
> Looking at the PR, there is one thing I have a 'bad feeling' with.
> And that is that everything is done in an eager way.
> E.g. we now maintain another list, the contentModel, even if you don't need
> it.
> I see why this API can be useful. And I even needed something like this, just
> not ver
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 ListVi
Hi Robert,
> This requires that a MenuButton always has a text, however a Skin could
> exist that does not contain any text node (but only a bitmap, a simple
> shape, etc.). AFAIK Skins separate controls from their concrete
> representation.
But that's the point of the content graph. A MenuButton
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 th
From a testing perspective it seems a good idea to have a more abstract
"document graph" to find certain elements in the UI (to check their
state is correct).
However I see two problems, shown as inline comments below...
Am 13.04.23 um 20:55 schrieb Michael Strauß:
Now also suppose a method
Some comments are inline.
I think this may be a good idea, but I would like to know more about the
use cases.
All I can think of is that it *may* be useful when you want to persist a
Scene (or the states involved); but as you're building the Scene
yourself, you should already be aware of how
