> Refactoring and renaming changes to some of the D3D pipeline files and a few
> changes on the Java side. These are various "leftovers" from previous issues
> that we didn't want to touch at the time in order to confine the scope of the
> changes. They will make future work easier.
>
> Since
> Refactoring and renaming changes to some of the D3D pipeline files and a few
> changes on the Java side. These are various "leftovers" from previous issues
> that we didn't want to touch at the time in order to confine the scope of the
> changes. They will make future work easier.
>
> Since
On Sun, 25 Dec 2022 03:28:27 GMT, Nir Lisker wrote:
>> Refactoring and renaming changes to some of the D3D pipeline files and a few
>> changes on the Java side. These are various "leftovers" from previous issues
>> that we didn't want to touch at the time in order to confine the scope of
>>
> Refactoring and renaming changes to some of the D3D pipeline files and a few
> changes on the Java side. These are various "leftovers" from previous issues
> that we didn't want to touch at the time in order to confine the scope of the
> changes. They will make future work easier.
>
> Since
One thing you could try still, whether acceptable or not, is to call
`applyCss` on the border pane before calling the count function.
As for the "and any children", I'm not sure how you should interpret
that. For a SplitPane, the nodes that are part of it are in the items
list (you don't add
That’s interesting. It leads me to wonder what is the expected result from a
call to lookupAll in various scenarios. If, after the window was showing, the
SplitPane divider is pushed all the way to one size such that the skin can
potentially choose to leave the hidden child out of the scene
Hi,
In this case, this is because SplitPane doesn't actually add its split
items as children -- only its Skin does this. Skins are AFAIK installed
after a CSS pass.
In the split pane case, I guess a Skin could choose to completely leave
out a child if its splitter completely hides it (ie,