Withdrawn: 8092272: [D3D 3D] Need a robust 3D states management for texture

[duke]

On Wed, 8 Nov 2023 22:30:34 GMT, Nir Lisker  wrote:

> Moves the filter setting of the samplers from the device parameters 
> configuration to the use-site, allowing for dynamic changes in the sampler. 
> This PR does internal plumbing work only to bring it close to the ES2 
> pipeline. A followup PR will create the public API.
> 
> Summary of the changes:
> * Created a new (internal for now) `TextureData` object that is intended to 
> contain all the data of texture (map) of `PhongMaterial`, such as filters, 
> addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** 
> as a starting point, more settings can be added later.
> * Creates an update mechanism from the Java side material to the native D3D 
> layer. The public API `PhoneMaterial` is *not* changed yet. The peer 
> `NGPhongMaterial` is configured to receive update from the public 
> `PhongMaterial` when the public API is created via new 
> `ObjectProperty` properties.
> * Small refactoring in the D3D layer with a new map types enum to control the 
> texture settings more easily.
> 
> The JBS issue lists some regressions in a comment, but I couldn't reproduce 
> them. It looks like the sampler settings needed to be added anywhere, and 
> that was the easiest to do at the time. Now they were just moved.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.org/jfx/pull/1281

ImageView has artifacts when uiScale is set on Linux

[Christopher Schnick]

Hello,

due to the scaling problems on Linux with 
https://bugs.openjdk.org/browse/JDK-8326428, I tried to implement a 
workaround by manually setting glass.gtk.uiScale to the appropriate 
value. However, when this value is not 100%, small images, in this case 
40x40, often have artifacts around the borders:


Original image:

The same does not happen when using the same uiScale on Windows. This 
was done with the latest ea build on Ubuntu 23.10. The exact scale does 
not matter as long it is not 100%.


This is the code I used:

|public class ImageSize extends Application {

    public static void main(String[] args) {
    System.setProperty("glass.gtk.uiScale", "400%");
    Application.launch(ImageSize.class, args);
    }

    @Override
    public void start(Stage primaryStage) throws Exception {
    var img = 
"data:image/png;base64,iVBORw0KGgoNSUhEUgAAACgoCAYAAACM/rhtCXBIWXMAAAEuAAABLgF7cRpNGXRFWHRTb2Z0d2FyZQB3d3cuaW5rc2NhcGUub3Jnm+48GgAACJhJREFUWIXNmHt0VNUVxn/n3nkmE/KCZDJBkCBIxRBIgqBBEKSAi2i7ZAG1tauCheUjARUp6lpW66K11CICoViLq7TlYZ9YFaGtlYfSKJiglPAQwQWBSUzIa5JJ5nlP/7hhXplMEnF1+f01c+539vnO2fvsve+FrznEV2GkcJmzCMlTwM0CPMB2TKyvWuu4fLW2r0pgcdmlEk3hCaSYG8eWW8KrQbQXjm0cevH/KrBouXOKlHIVUpT2g+4D/hjUtNWfbBr66UDXGoBAKQrLnaXAUyAmD3QhQEPIt0VQPFO1yVH91Ql8ViqFTc65IJ4BihJRjaogKCWaltCiRMjdQqirq9bbP/zSAouWSqNmrr9HIJ8ExvRlCOC3j2bS3KGx4jct/aEj4ZBArqnemPtmbxxD7MD8+VI9Z69fKqlbJWB4v1bqRmqygi/Qf76AEhBvTCh3HhKC1dUbHHtjOUrswFm7c4dE/ooBigNobte43BYc6DRdqGTPhDLnzxIKLHi4biyIBQNeoRs2q8Bq/vKZSwhWFS+/dH3kWJSLVUWbPpCLbTUJpow1M3mMmRF2A6McRkZkG3lxSTqnLwY4cNzDqVr/QDQqmlRmAqfjCkQqJQgZuSMenzeI/5zwcuiEN7wrFe6dYeP7M5JJS46OEoMK0/ItTMuHpXfYqLngZ/PudipPeqN4swutpCQJ/vJ+Z9S4kLIE2BRSHPO0JPKv0SCYU2TlxSUZzCq0ApCdprL1scGU35lCWrKClFBzwc+/jnpC894+0sWlJj0Wxw4zUvFgBk/fk4pR1b1z74xkfvqDNEpvSupxhFIyNUrSlR8Fj9bmqgG1R0nKTld55FspzJxg5Z9VXYwfacKergKw56MuXtnTwYXGABNHm3i5LBOAqT+qp9MrKbzORPmdg8i/1gjAB6e8BIJwyw1m/vSem1f2dNDm7pk0hcLwqvWOCxDhYiWo3NqDCXzREuTJra04m4Lc900bAD6/5OltrbwTcWop1rAzbFYFtydI1Rkfi9Zd5sG5Kdw/y8bkMWYAfvyHVnYf6Yq3HACaJkuACxDhYiGVkl5nAC0ROzUYBNfnGlEjAsQWKdASvmgpVoUR2dGhfr4hcbLU86OOCIFySm8TksyCRd2n52wOoghYPMvGluWZODLUbiFhUVfEFo8y8doTg5lRYEFKqGvW4/Kh0pSEAkGEtCgAYx9qsEnBjb3Rp4+zkJas0N6l8b1fXGb7PjcA40aY2LlqCN+9LZnZ3ZcIYMGUJFbOG8Tmskyy01Q0DVa/1sbjr+olcNL1ZnIz1UQK84uWNqeGBFqF/2bilL0ruPVGCwD//tiDq1PjxV0u1u1yoUk9Oa+4exBjhxtD/DnFVr4zLRlFgNcvWflqC69XdnKq1s/pi3pevH28JZFARZo8k0MCNZWE8Zdn17V/eNoXGtu2z81zO1qjeJ85A1y8HC51Pr/koU3N7P9v+DJ9cErPh6McRhJBKromPVikSCgwK02nxQZ3fUtYzN6qLhb+vJEFzzdyxqmfUqdP0tAaXZtruzeQk5HQxQjJFADD/PlSPUvdpERknx+wgkHR42fqjWamj7OQnR5e5MoF8PolDa0aoxyQlqzw5rNZnKsPcPC4h8OnfQPpkCeNfbbGZDiXVVcA9HqtHBkqotvq1scGo/Tof3TcfUsSbW6NtGSFiaNNUc/y7Aby7Dbum0momU2yCJLMgk6vjGNNpxhbMgrEhGWXyoUUGyKfzCiwMLvQyjVZKnl2Q6hEAUipp5qzdX7O1QUYnKpSepO1h/VAEDbvbifJIsizGxiZY2BopiFqg00ujZO1fs43BHjrcBefXoppLCSPGYQUebHGF8+yMXSwyqEaL39+r5OJo03MLrTibA6y8PnGqF2PG2GKK9Djk2zf58YfDHPTbQpv/yQLk1Hw1uEuKk95mTjKxB3FVkbnGnmgoinaiMJwA0J8how+5sUvNSE1Qsbf/cTD9HwLjgyVwutMvF8T7kzumhQWt+51F4UjTUzLt2CzCmZOsLDno3BJmzclCZNR0OWTrP2bC1enxt6PulCUth4b7D7BGiVgEluJ6L9ATw+RO29za+w8oCfnJxekMihJ95PNKphTrAs8dMLLtnfdrH6tDbdHn7vg1nC3Mj7PxJLZeqjv2O/G1RkunZpGjxctATVmQ3CbcuyXdndQ0+4CopNaDLb8o4PzDQHs6SobHsggxapQelMSVpNA02DDGy5Ab/t/904HoLt/zDVGbhhm5IX70zGocLYuwJa9HYmWAmiRweC3K9dd0xWK/sIy52wEu4FeE9S12Qa2LM8k3aZQ2xhAUQS5mSp//6CT53aE3WQxCXY9PYSsVJWTtX5G2g2YjIIvWoMsWd8U6hV7gSalKD1akbOHSDF1h9eezZm0IgDc3tvMVrfG/mNebv6GmWFZhpCr3+0ugVLCoCSFa7MNZKfpGWBIqoqqCs44/Sx7uSWq0sSDQKysrsj5ffh/FKQoLK/fCXJhIiMWk+CV8syo+psIx8/7WbKhCZ+/15x3BdurNzrujRyISbtCmg2BRUBVIisen0RR4LJL44W/ujh43ENDWxB/UOLzSy40Bqg86aXizXaa2zU0TfYpTkg+Fl6W9hiPR57wsHO4UDgCDIn3/LZxFtb+MJ0VW1rYf8wTjxLCzPEW1ixOZ/mvm6PSUwyaAlKZeKzC/nnsg7iF6+gmx3lgHtDjndGg6qmmoS3IweOJxQHsO+ahuV3jqYWpoZIZA79EzIsnrleBANUbHe8JycrYcYHg9EU/L+1q7+sjEQBBDV563cXn9YG4AqVk2dGNOQd6m99nc1G0zLlFSu7vW8qXgdxavTF3USJGryd4BSkubxmSPj+TDRyi0kXnA32y+mOq6JHGHBnwH0GQe/XCAKiTMlB8tGKYsy9iv/tH/WaLNSCnAglfKPrAyaAmln6yKafmKmx8ffA/40AyV2Na31IASUVORK5CYII=";

    var r = new ImageView(img);
    r.setFitWidth(40);
    r.setFitHeight(40);

    var s = new StackPane(r);
    s.setBackground(Background.fill(Color.BLACK));

    var scene = new Scene(s, 100, 100);
    primaryStage.setScene(scene);
    primaryStage.setTitle("Test");
    primaryStage.show();
    }
}|

Is this a bug or a limitation in the renderer?

Best
Christopher Schnick

[jfx21u] Integrated: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView

[Jose Pereda]

On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda  wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit 
> [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Jose Pereda on 21 Dec 2023 and 
> was reviewed by Andy Goryachev.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f83dfdd4
Author:Jose Pereda 
URL:   
https://git.openjdk.org/jfx21u/commit/f83dfdd4ee6e7c87551a9be70dcdebbd6b3ad403
Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod

8321970: New table columns don't appear when using fixed cell size unless 
refreshing tableView

Reviewed-by: jvos
Backport-of: ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd

-

PR: https://git.openjdk.org/jfx21u/pull/44

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3]

[Kevin Rushforth]

On Fri, 23 Feb 2024 22:10:02 GMT, Michael Strauß  wrote:

> > What about SWT ? It looks like SWT also supports dark mode since version 
> > 4.12 [1][2].
> > [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac 
> > [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357
> 
> I haven’t tested this in combination with SWT, have you?

I just did and it works as expected (so no special-casing of an SWT application 
is needed).

-

PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1962183229

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4]

[Kevin Rushforth]

On Fri, 23 Feb 2024 21:58:37 GMT, Michael Strauß  wrote:

>> Platform preferences detection doesn't pick up effective macOS system 
>> preferences if AWT owns the NSApplication and has set its NSAppearance to a 
>> fixed value.
>> 
>> The workaround is to set the system property 
>> "apple.awt.application.appearance=system".
>> 
>> If this property is not set, the following warning will be emitted if a 
>> JavaFX application attempts to use the platform preferences API:
>> 
>> 
>> WARNING: Reported preferences may not reflect the macOS system preferences 
>> unless the sytem
>> property apple.awt.application.appearance=system is set. This warning can be 
>> disabled by
>> setting javafx.preferences.suppressAppleAwtWarning=true.
>
> Michael Strauß has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Break warning message into separate lines

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1367#pullrequestreview-1899133239

Re: RFR: 8314147: Updated the PhongMaterial documentation [v3]

[Kevin Rushforth]

On Thu, 22 Feb 2024 22:28:40 GMT, Nir Lisker  wrote:

>> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass 
>> `Material`). Except for the introduction, I divided the documentation into 3 
>> sections: qualitative explanation, mathematical model (I wouldn't think it 
>> necessary, but the current doc explains it), and examples.
>> 
>> The reason for the verbosity of the doc is that I envisioned 2 target 
>> audiences for this class. One is a Java developer who wants to understand 
>> the terminology and workings of computer graphics or of the artists who are 
>> already familiar with this domain. (How many Java developers know what 
>> diffuse, specular and normal maps are?) The other is an artist who is 
>> already familiar with the domain, but wants to see how this class compares 
>> with other renderers. For this reason, I looked at the terminology used by 
>> engines like Blender, Maya, UE4 and Unity and tried to mention the 
>> comparisons (like bump vs. height vs. normal maps, or specular vs. 
>> roughness/smoothness).
>> 
>> The examples I chose and some of the schematics are not the best, looking at 
>> it retroactively, but I want to give enough time for reviewers and get this 
>> into 22.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Revert unintended formatting

I did a first pass of the updated PhongMaterial docs. Nice work! I'll need more 
time to go through it in detail (and definitely will want Ambarish and Lukasz 
to review it as well), but I like the structure, the explanations, and the 
illustrations.

-

PR Comment: https://git.openjdk.org/jfx/pull/1378#issuecomment-1962177376

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2]

[Kevin Rushforth]

On Fri, 23 Feb 2024 22:32:23 GMT, Andy Goryachev  wrote:

>> `@return` statements usually state this condition explicitly, like 
>> `Map#get`: "the value to which the specified key is mapped, or `null` if 
>> this map contains no mapping for the key".
>
> My point is that it should be mentioned in the first paragraph then.  It can 
> be repeated in @return later, if you prefer.  Map.get() does indeed mention 
> this in the first paragraph:
> 
> ![Screenshot 2024-02-23 at 14 30 
> 02](https://github.com/openjdk/jfx/assets/107069028/977a6dbc-c0b0-4a00-a14d-8ff40353c365)

Given that the changes are so far limited to spelling and formatting (code 
style for null), I think it would be fine to limit the changes in this PR to 
what he has already done.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501267342

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2]

[Andy Goryachev]

On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker  wrote:

>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs 
>> in `Node` and `Scene`.
>> 
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
>> system property, while for `Node` it isn't (which means `SubScene` will be 
>> different from `Scene`). Not sure if this is intended.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Addressed review comments

Marked as reviewed by angorya (Reviewer).

-

PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1899094754

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2]

[Kevin Rushforth]

On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker  wrote:

>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs 
>> in `Node` and `Scene`.
>> 
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
>> system property, while for `Node` it isn't (which means `SubScene` will be 
>> different from `Scene`). Not sure if this is intended.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Addressed review comments

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1899088659

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Andy Goryachev]

On Fri, 23 Feb 2024 22:28:59 GMT, Nir Lisker  wrote:

> Only `Scene` has the RTL system property checked.

I suppose because Scene must INHERIT this value from the system?

-

PR Comment: https://git.openjdk.org/jfx/pull/1379#issuecomment-1962094000

Integrated: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline

[Martin Fox]

On Fri, 26 Jan 2024 17:32:02 GMT, Martin Fox  wrote:

> In the Mac glass code the presence of "marked" text (which is tracked in the 
> nsAttrBuffer) signals that an IME is active. In this state the current code 
> assumes that when NSTextInputContext handles a `keyDown:` it will either 
> generate a call to `insertText:replacementRange:` or one of the routines that 
> manipulates the marked (composed) text. But this bug shows that sometimes the 
> IME acts on the event without generating any calls back into glass at all.
> 
> In this PR the logic is simplified: if the NSTextInputContext handles the 
> `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. 
> Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no 
> longer assumes we can catch callbacks to update it correctly.
> 
> The existing code also assumes that the composition phase ends when the 
> NSTextInputContext calls `insertText:replacementRange` to commit the text. 
> This is true but if the user tries to use a dead-key sequence to generate a 
> non-existent character (like an accented 'q') the context will call 
> `insertText` twice while handling one key down event. In that case we can't 
> exit the composition mode upon seeing the first `insertText` call since it 
> will cause us to mis-handle the second one. This PR defers exiting 
> composition mode until the end of `keyDown:`.
> 
> I also updated a few deprecated constants so this file no longer generates 
> compiler warnings.

This pull request has now been integrated.

Changeset: d9263ab2
Author:Martin Fox 
URL:   
https://git.openjdk.org/jfx/commit/d9263ab268d33104279755dc1de139bd0835fdd7
Stats: 60 lines in 3 files changed: 35 ins; 10 del; 15 mod

8301900: TextArea: Committing text with ENTER in an IME window inserts newline
8088172: Mac: On German keyboard, pressing <+> inserts two apostrophes 
instead of one
8089803: [Mac, TextArea] Japanese IME, caret moves to the next line when 
pressing Return to select a candidate.

Reviewed-by: kcr, angorya

-

PR: https://git.openjdk.org/jfx/pull/1351

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2]

[Andy Goryachev]

On Fri, 23 Feb 2024 21:58:30 GMT, Nir Lisker  wrote:

>> I don't mind either way.
>
> `@return` statements usually state this condition explicitly, like `Map#get`: 
> "the value to which the specified key is mapped, or `null` if this map 
> contains no mapping for the key".

My point is that it should be mentioned in the first paragraph then.  It can be 
repeated in @return later, if you prefer.  Map.get() does indeed mention this 
in the first paragraph:

![Screenshot 2024-02-23 at 14 30 
02](https://github.com/openjdk/jfx/assets/107069028/977a6dbc-c0b0-4a00-a14d-8ff40353c365)

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501237620

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Nir Lisker]

On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker  wrote:

> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in 
> `Node` and `Scene`.
> 
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
> system property, while for `Node` it isn't (which means `SubScene` will be 
> different from `Scene`). Not sure if this is intended.

By the way, is the difference in the default values between `Node` and `Scene` 
intentional? Only `Scene` has the RTL system property checked.

-

PR Comment: https://git.openjdk.org/jfx/pull/1379#issuecomment-1962085277

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc [v2]

[Nir Lisker]

> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in 
> `Node` and `Scene`.
> 
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
> system property, while for `Node` it isn't (which means `SubScene` will be 
> different from `Scene`). Not sure if this is intended.

Nir Lisker has updated the pull request incrementally with one additional 
commit since the last revision:

  Addressed review comments

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1379/files
  - new: https://git.openjdk.org/jfx/pull/1379/files/dac77a49..a3c375df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1379=01
 - incr: https://webrevs.openjdk.org/?repo=jfx=1379=00-01

  Stats: 53 lines in 2 files changed: 21 ins; 25 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1379.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1379/head:pull/1379

PR: https://git.openjdk.org/jfx/pull/1379

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3]

[Michael Strauß]

On Mon, 19 Feb 2024 17:13:58 GMT, Anirvan Sarkar  wrote:

> What about SWT ? It looks like SWT also supports dark mode since version 4.12 
> [1][2].
> 
> [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac 
> [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357

I haven’t tested this in combination with SWT, have you?

-

PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-1962068535

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3]

[Michael Strauß]

On Fri, 23 Feb 2024 20:14:43 GMT, Kevin Rushforth  wrote:

>> Michael Strauß has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   address review comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java
>  line 483:
> 
>> 481: 
>> 482: if (!AWT_SYSTEM_APPEARANCE.equals(awtAppearanceProperty)) {
>> 483: Logging.getJavaFXLogger().warning(String.format(
> 
> Minor: Maybe add newlines to break this message into two or three separate 
> lines?

Done. I've also moved the `checkSystemAppearance` assignment out of the if 
branch (it should be unconditionally set to `false` after the first call).

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1501215285

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Nir Lisker]

On Fri, 23 Feb 2024 19:38:20 GMT, Kevin Rushforth  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java 
>> line 187:
>> 
>>> 185:  * Returns the child's bottom anchor constraint, if set.
>>> 186:  * @param child the child node of an anchor pane
>>> 187:  * @return the offset from the bottom of the anchor pane, or 
>>> {@code null} if no bottom anchor was set
>> 
>> minor suggestion: move explanation of when it returns null to the 
>> description,  i.e.:
>> 
>> 
>> Returns the child's bottom anchor constraint, if set, otherwise returns 
>> {@code null}.
>> 
>> @return the offset from the bottom of the anchor pane, or {@code null}
>
> I don't mind either way.

`@return` statements usually state this condition explicitly, like `Map#get`: 
"the value to which the specified key is mapped, or `null` if this map contains 
no mapping for the key".

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501214852

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4]

[Michael Strauß]

> Platform preferences detection doesn't pick up effective macOS system 
> preferences if AWT owns the NSApplication and has set its NSAppearance to a 
> fixed value.
> 
> The workaround is to set the system property 
> "apple.awt.application.appearance=system".
> 
> If this property is not set, the following warning will be emitted if a 
> JavaFX application attempts to use the platform preferences API:
> 
> 
> WARNING: Reported preferences may not reflect the macOS system preferences 
> unless the sytem
> property apple.awt.application.appearance=system is set. This warning can be 
> disabled by
> setting javafx.preferences.suppressAppleAwtWarning=true.

Michael Strauß has updated the pull request incrementally with one additional 
commit since the last revision:

  Break warning message into separate lines

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1367/files
  - new: https://git.openjdk.org/jfx/pull/1367/files/5c743df7..8fdbc624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1367=03
 - incr: https://webrevs.openjdk.org/?repo=jfx=1367=02-03

  Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1367.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1367/head:pull/1367

PR: https://git.openjdk.org/jfx/pull/1367

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Kevin Rushforth]

On Fri, 23 Feb 2024 20:16:55 GMT, Nir Lisker  wrote:

> I suggest to move the doc to the field.

Yeah that's even better.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501132703

Re: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v3]

[Kevin Rushforth]

On Sat, 17 Feb 2024 18:11:09 GMT, Michael Strauß  wrote:

>> Platform preferences detection doesn't pick up effective macOS system 
>> preferences if AWT owns the NSApplication and has set its NSAppearance to a 
>> fixed value.
>> 
>> The workaround is to set the system property 
>> "apple.awt.application.appearance=system".
>> 
>> If this property is not set, the following warning will be emitted if a 
>> JavaFX application attempts to use the platform preferences API:
>> 
>> 
>> WARNING: Reported preferences may not reflect the macOS system preferences 
>> unless the sytem
>> property apple.awt.application.appearance=system is set. This warning can be 
>> disabled by
>> setting javafx.preferences.suppressAppleAwtWarning=true.
>
> Michael Strauß has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address review comments

Looks good with one minor formatting suggestion (but I'll approve it as is).

modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java 
line 483:

> 481: 
> 482: if (!AWT_SYSTEM_APPEARANCE.equals(awtAppearanceProperty)) {
> 483: Logging.getJavaFXLogger().warning(String.format(

Minor: Maybe add newlines to break this message into two or three separate 
lines?

-

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1367#pullrequestreview-1898861689
PR Review Comment: https://git.openjdk.org/jfx/pull/1367#discussion_r1501125311

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Nir Lisker]

On Fri, 23 Feb 2024 19:44:06 GMT, Andy Goryachev  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272:
>> 
>>> 6270:  * of text in both worlds.
>>> 6271:  *
>>> 6272:  * @defaultValue if the system property {@code 
>>> javafx.scene.nodeOrientation.RTL} is {@code true},
>> 
>> Restore the `@return` to avoid a warning.
>
> it seems that placing javadoc at the property declaration instead of the 
> method which returns said property eliminates the warning. 
> See for example Stage:1329

Yes, this is why I was surprised that new warnings showed up. The `@return` 
text is auto-generated for properties, so why would a return tag be needed? I 
guess the doc tool doesn't understand that when the doc is placed on the 
property getter instead of on the field, which I think is a bug.

I suggest to move the doc to the field.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501126942

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Andy Goryachev]

On Fri, 23 Feb 2024 19:34:41 GMT, Kevin Rushforth  wrote:

>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs 
>> in `Node` and `Scene`.
>> 
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
>> system property, while for `Node` it isn't (which means `SubScene` will be 
>> different from `Scene`). Not sure if this is intended.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272:
> 
>> 6270:  * of text in both worlds.
>> 6271:  *
>> 6272:  * @defaultValue if the system property {@code 
>> javafx.scene.nodeOrientation.RTL} is {@code true},
> 
> Restore the `@return` to avoid a warning.

it seems that placing javadoc at the property declaration instead of the method 
which returns said property eliminates the warning. 
See for example Stage:1329

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501100898

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v3]

[Kevin Rushforth]

On Fri, 2 Feb 2024 18:43:19 GMT, Martin Fox  wrote:

>> In the Mac glass code the presence of "marked" text (which is tracked in the 
>> nsAttrBuffer) signals that an IME is active. In this state the current code 
>> assumes that when NSTextInputContext handles a `keyDown:` it will either 
>> generate a call to `insertText:replacementRange:` or one of the routines 
>> that manipulates the marked (composed) text. But this bug shows that 
>> sometimes the IME acts on the event without generating any calls back into 
>> glass at all.
>> 
>> In this PR the logic is simplified: if the NSTextInputContext handles the 
>> `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. 
>> Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it 
>> no longer assumes we can catch callbacks to update it correctly.
>> 
>> The existing code also assumes that the composition phase ends when the 
>> NSTextInputContext calls `insertText:replacementRange` to commit the text. 
>> This is true but if the user tries to use a dead-key sequence to generate a 
>> non-existent character (like an accented 'q') the context will call 
>> `insertText` twice while handling one key down event. In that case we can't 
>> exit the composition mode upon seeing the first `insertText` call since it 
>> will cause us to mis-handle the second one. This PR defers exiting 
>> composition mode until the end of `keyDown:`.
>> 
>> I also updated a few deprecated constants so this file no longer generates 
>> compiler warnings.
>
> Martin Fox has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains seven commits:
> 
>  - Now handling ESC ending the composition state. Minor setEnabled cleanup.
>  - Merge remote-tracking branch 'upstream/master' into macimefixes
>  - When IM enabled state changes we dismiss the IM window.
>  - Merge remote-tracking branch 'upstream/master' into macimefixes
>  - Comment tweaks
>  - Merge remote-tracking branch 'upstream/master' into macimefixes
>  - Modified method of determing which keyDowns are sent as KeyEvents.

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1351#pullrequestreview-1898820773

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Kevin Rushforth]

On Fri, 23 Feb 2024 18:31:10 GMT, Andy Goryachev  wrote:

>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs 
>> in `Node` and `Scene`.
>> 
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
>> system property, while for `Node` it isn't (which means `SubScene` will be 
>> different from `Scene`). Not sure if this is intended.
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java 
> line 187:
> 
>> 185:  * Returns the child's bottom anchor constraint, if set.
>> 186:  * @param child the child node of an anchor pane
>> 187:  * @return the offset from the bottom of the anchor pane, or {@code 
>> null} if no bottom anchor was set
> 
> minor suggestion: move explanation of when it returns null to the 
> description,  i.e.:
> 
> 
> Returns the child's bottom anchor constraint, if set, otherwise returns 
> {@code null}.
> 
> @return the offset from the bottom of the anchor pane, or {@code null}

I don't mind either way.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501096059

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Kevin Rushforth]

On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker  wrote:

> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in 
> `Node` and `Scene`.
> 
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
> system property, while for `Node` it isn't (which means `SubScene` will be 
> different from `Scene`). Not sure if this is intended.

The changes to the docs look fine, although I note the same additional warnings 
that Andy saw (restoring the `@return` will fix it; the text after the 
`@return` doesn't matter, since it is unused).

Also, I think it would be better to revert all code changes, even though they 
look harmless.

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6449:

> 6447: EFFECTIVE_ORIENTATION_LTR | AUTOMATIC_ORIENTATION_LTR;
> 6448: 
> 6449: private static final NodeOrientation DEFAULT_NODE_ORIENTATION = 
> NodeOrientation.INHERIT;

This is unrelated to the doc change (and the addition of a static final const 
makes it not strictly a doc-only change). Presuming that you want to backport 
this to jfx22, I recommend to revert this change. Especially since the RC 
deadline is next week.

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6465:

> 6463:  * of text in both worlds.
> 6464:  *
> 6465:  * @defaultValue {@code NodeOrientation.INHERIT}

The `@return` is still needed (although unused) to avoid a warning.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6245:

> 6243: 
> 6244: @SuppressWarnings("removal")
> 6245: private static final NodeOrientation DEFAULT_NODE_ORIENTATION =

Same comment as in Node.java -- I recommend reverting this change if you intend 
to backport it to jfx22.

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272:

> 6270:  * of text in both worlds.
> 6271:  *
> 6272:  * @defaultValue if the system property {@code 
> javafx.scene.nodeOrientation.RTL} is {@code true},

Restore the `@return` to avoid a warning.

-

PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1898671234
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501010198
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501010794
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501011782
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501093086

Re: Proposal: RichTextArea Control (Incubator)

[Nir Lisker]

Hi all,

I don't use RT controls, so I can't comment about the specifics of this or
other implementations. However, people raised some good points that I would
like to be more specific about.

1. Can the "components" of the RTA be separated out so that other controls
can use them? For example, colored text segments and highlights can be
useful in any text control, like Label and TextField.
2. About creating new controls and the difficulty involved, aren't the long
discussions about splitting the behavior, skin, input etc. and John's
proposal in that regard addressing exactly that, giving the ability to
compose "facets" into controls?
3. It's obvious that the bar for what goes into a library (JavaFX, JDK and
all other GUI toolkits) is fluid. We don't *have* to provide a Button
because any 3rd party library can make one, but we all agree that it's a
good idea. More complex controls, like color picker and date picker could
be more controversial as they are not entirely standardized, but I think
it's OK to have them. The question is, how far does this go? Perhaps what
can help here is to look at various GUI toolkits and see what they provide
so we know what users expect. It also matters if they are intended for use
on mobile, in which case the set of controls is somewhat different.

- Nir

On Wed, Feb 21, 2024 at 8:07 PM Andy Goryachev 
wrote:

> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>

Re: RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Andy Goryachev]

On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker  wrote:

> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in 
> `Node` and `Scene`.
> 
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
> system property, while for `Node` it isn't (which means `SubScene` will be 
> different from `Scene`). Not sure if this is intended.

looks good (with minor suggestion)
however, this change adds 2 javadoc warnings which need to be addressed,  I 
would think .

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 6465:

> 6463:  * of text in both worlds.
> 6464:  *
> 6465:  * @defaultValue {@code NodeOrientation.INHERIT}

adds a javadoc warning:


/Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/src/main/java/javafx/scene/Node.java:6468:
 warning: no @return
public final ObjectProperty nodeOrientationProperty() {
 ^

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6273:

> 6271:  *
> 6272:  * @defaultValue if the system property {@code 
> javafx.scene.nodeOrientation.RTL} is {@code true},
> 6273:  * {@code NodeOrientation.RIGHT_TO_LEFT}, otherwise {@code 
> NodeOrientation.INHERIT}

adds a javadoc warning:


/Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java:6276:
 warning: no @return
public final ObjectProperty nodeOrientationProperty() {
 ^

modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 
187:

> 185:  * Returns the child's bottom anchor constraint, if set.
> 186:  * @param child the child node of an anchor pane
> 187:  * @return the offset from the bottom of the anchor pane, or {@code 
> null} if no bottom anchor was set

minor suggestion: move explanation of when it returns null to the description,  
i.e.:


Returns the child's bottom anchor constraint, if set, otherwise returns {@code 
null}.

@return the offset from the bottom of the anchor pane, or {@code null}

modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 
209:

> 207:  * Returns the child's right anchor constraint, if set.
> 208:  * @param child the child node of an anchor pane
> 209:  * @return the offset from the right of the anchor pane, or {@code 
> null} if no right anchor was set

and here

-

Changes requested by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1379#pullrequestreview-1898708803
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501034793
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501035303
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501033228
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501033642

Re: UI scaling issues when physical and logical screen resolutions differ on Linux

[Thiago Milczarek Sayão]

Christopher,

 -Dglass.gtk.uiScale=`gsettings get org.gnome.desktop.interface
text-scaling-factor`

Probably works.


Em qua., 21 de fev. de 2024 às 01:57, Christopher Schnick <
crschn...@xpipe.io> escreveu:

> So I tested this on my Asahi Fedora Linux KDE setup. So you were right
> about the scaling-factor being set to 1, but I'm still a little bit
> confused about this situation.
>
> If I go into the KDE settings, and change the display scaling to 150% for
> example, other (native) applications somehow get scaled appropriately.
> However, the scaling-factor property in gsettings is an integer and gets
> rounded down. So if I set display scaling to 150% in the settings, it will
> still get rounded down to one, leading to a wrong scaling for JavaFX
> applications. I would argue that JavaFX applications not scaling correctly
> on KDE systems is not a small issue as it makes some applications unusable
> unless the developer add support for custom scaling explicitly. So I have
> two questions:
> - Is the default dpi calculation also error prone? If not, why not always
> use the manual calculation on KDE systems
> - Are there better alternatives to the gsettings scaling-factor? Something
> like org.gnome.desktop.interface text-scaling-factor
> On 16/02/2024 21:31, Martin Fox wrote:
>
> Hi Christopher,
>
> This may be a side-effect of using KDE. To determine the UI scale the
> JavaFX code consults the “scaling-factor” setting in the
> “org.gnome.desktop.interface” schema. You can check this on the command
> line:
>
> gsettings get org.gnome.desktop.interface scaling-factor
>
> This should be 0 so JavaFX can compute the scale itself. If it’s greater
> than 0 that’s the value JavaFX will use for the UI scale.
>
> It appears that a KDE install can set this value to 1. In my case I
> started with the ARM version of Ubuntu server and then installed KDE
> (kubuntu-desktop) and afterward the scaling-factor was 1. This doesn’t
> happen when installing the standard GNOME desktop.
>
> Martin
>
> On Feb 13, 2024, at 2:13 AM, Christopher Schnick 
>  wrote:
>
> Hello,
>
> several users of our JavaFX applications have reported that the UI scale
> is too small when the physical and logical screen resolutions differ on
> Linux. For example in this case
>
> 
>
> there is an implicit scaling factor of 150% included as the monitor is a
> 4k display but is using a lowered resolution of 2560x1440. This is then
> further stretched as the OS resolution is 1920x1080, but the main problem
> is that the 150% factor is somehow not getting picked up and JavaFX is
> treating this as a 4k display, thus making everything too small. For now
> these users can use -Dglass.gtk.uiScale=1.5 but that is not a nice
> solution to this problem.
>
> Best
> Christopher Schnick
>
>
>

RFR: 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc

[Nir Lisker]

Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in 
`Node` and `Scene`.

Note that the default value for a `Scene`'s `NodeOrientation` depends on a 
system property, while for `Node` it isn't (which means `SubScene` will be 
different from `Scene`). Not sure if this is intended.

-

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/1379/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1379=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325550
  Stats: 41 lines in 3 files changed: 4 ins; 6 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1379.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1379/head:pull/1379

PR: https://git.openjdk.org/jfx/pull/1379

Re: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2]

[Kevin Rushforth]

On Thu, 22 Feb 2024 23:13:26 GMT, Marius Hanl  wrote:

>> This PR fixes the dialog freeze problem once and for all. 
>> 
>> This one is a bit tricky to understand, here is how it works:
>> This bug happens on every platform, although the implementation of nested 
>> event loops differs on every platform.
>> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we 
>> have an own implementation of a nested event loop (while loop), controlled 
>> by a boolean flag.
>> 
>> Funny enough, the reason why this bug happens is always the same: Timing.
>> 
>> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 
>> 2. This will call native code to get out of the nested event loop, e.g. on 
>> Windows we try to break out of the while loop with a boolean flag, on Linux 
>> we call `gtk_main_quit`.
>> 3. Now, if we immediately open a new dialog, we enter a new nested event 
>> loop via `_enterNestedEventLoop`, as a consequence we do not break out of 
>> the while loop on Windows (the flag is set back again, the while loop is 
>> still running), and we do not return from `gtk_main` on Linux.
>> 4. And this will result in the Java code never returning and calling 
>> `notifyLeftNestedEventLoop`, which we need to recover the UI.
>> 
>> So it is actually not trivial to fix this problem, and we can not really do 
>> anything on the Java side. We may can try to wait until one more frame has 
>> run so that things will hopefully be right, but that sounds rather hacky.
>> 
>> I therefore analyzed, if we even need to return from 
>> `_enterNestedEventLoop`. Turns out, we don't need to. 
>> There is a return value which we actually do not use (it does not have any 
>> meaning to us, other that it is used inside an assert statement).
>> Without the need of a return value, we also do not need to care when 
>> `_enterNestedEventLoop` is returning - instead we cleanup and call 
>> `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native 
>> code was called.
>> 
>> Lets see if this is the right approach (for all platforms).
>> Testing appreciated.
>> #
>> - [x] Tested on Windows
>> - [x] Tested on Linux
>> - [x] Tested on Mac
>> - [ ] Tested on iOS (although the nested event loop code is the same as for 
>> Mac) (I would appreciate if someone can do this as I have no access to an 
>> iOS device)
>> - [ ] Adjust copyright
>> - [ ] Write Systemtest
>
> Marius Hanl has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains three additional 
> commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjfx/master' into 
> JDK-8285893-dialog-freezing-略
>  - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop
>  - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen

I see the same failure with the most recent patch as I did yesterday. I looked 
over the changes, and I'm not convinced that this is the right approach.

One comment on your proposal:

> we also do not need to care when _enterNestedEventLoop is returning - instead 
> we cleanup and call notifyLeftNestedEventLoop in _leaveNestedEventLoop, after 
> the native code was called.

This changes one of the fundamental aspects of entering and exiting a nested 
event loop. This will need a lot more analysis to show why this is the right 
approach.

-

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1961735156

Re: [jfx21u] RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView

[Johan Vos]

On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda  wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit 
> [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Jose Pereda on 21 Dec 2023 and 
> was reviewed by Andy Goryachev.
> 
> Thanks!

Marked as reviewed by jvos (Reviewer).

-

PR Review: https://git.openjdk.org/jfx21u/pull/44#pullrequestreview-1898620272

Re: Proposal: RichTextArea Control (Incubator)

[Thiago Milczarek Sayão]

This is a good point, Martin.

I would expect the JavaFX RTA to be basic, but extendable - to allow
companies to offer commercial options for particular needs based on it. I
don't see a single RTA component that would be useful for every need.

Use case examples (that I could think of):
- An IDE code editor;
- A text message writer/viewer that would have emoticons, gifs;
- Maybe a collaborative app where multiple users write;

-- Thiago

Em sex., 23 de fev. de 2024 às 10:31, Martin Desruisseaux <
martin.desruisse...@geomatys.com> escreveu:

> Le 2024-02-23 à 13 h 34, Johan Vos a écrit :
>
> That is not to say that we should not do anything. On the contrary, I'd
> love it if we could do more. But in the right place. Stability and basic
> features inside OpenJFX, experiments and libraries in the ecosystem.
>
> JavaFX could have a "basic" Rich Text Area (RTA) for common needs such as
> syntax coloration, underlining errors, etc., and external projects such as
> Gluon could have more sophisticated controls for more advanced needs. I
> would appreciate a lot to have a Rich Text Area included in JavaFX for
> "basic" needs, because it would avoid adding another dependency. I'm always
> very reluctant to do the latter, because few projects are economical in
> their own dependencies. Many projects bring ton of dependencies, often
> outdated, often conflicting with other projects bringing different versions
> of the same dependencies.
>
> So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I
> would use the JavaFX one for e.g., syntax coloration, and if I need
> something more advanced I would look at the alternatives. This is the same
> situation as other controls such as DatePicker or ColorPicker: they are
> sufficient for "basic" needs, more elaborated alternatives may exist in
> other projects.
>
> Martin
>
>
>

Integrated: 8321603: Bump minimum JDK version for JavaFX to JDK 21

[Kevin Rushforth]

On Thu, 15 Feb 2024 20:38:14 GMT, Kevin Rushforth  wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK 
> 21**.
> 
> In order for JavaFX to be able to use newer JDK features, such as code 
> snippets (in API docs), record patterns, pattern matching for switch 
> statements, and so forth, we need to increase the minimum version of the JDK 
> required run the latest JavaFX. Additionally, there is an ongoing cost to 
> keeping JavaFX buildable and runnable on older versions of Java, and little 
> reason to continue to do so.
> 
> This is targeted to JavaFX 23, and must not be backported to any earlier 
> version. This needs a CSR and a release note.

This pull request has now been integrated.

Changeset: afa206b5
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx/commit/afa206b546a580a784d830712be174bb84f09ee9
Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod

8321603: Bump minimum JDK version for JavaFX to JDK 21

Reviewed-by: angorya, jvos, prr

-

PR: https://git.openjdk.org/jfx/pull/1370

Re: Proposal: RichTextArea Control (Incubator)

[Martin Desruisseaux]

Le 2024-02-23 à 13 h 34, Johan Vos a écrit :

That is not to say that we should not do anything. On the contrary, 
I'd love it if we could do more. But in the right place. Stability and 
basic features inside OpenJFX, experiments and libraries in the ecosystem.


JavaFX could have a "basic" Rich Text Area (RTA) for common needs such 
as syntax coloration, underlining errors, etc., and external projects 
such as Gluon could have more sophisticated controls for more advanced 
needs. I would appreciate a lot to have a Rich Text Area included in 
JavaFX for "basic" needs, because it would avoid adding another 
dependency. I'm always very reluctant to do the latter, because few 
projects are economical in their own dependencies. Many projects bring 
ton of dependencies, often outdated, often conflicting with other 
projects bringing different versions of the same dependencies.


So I do not see a JavaFX RTA and a Gluon RTA as mutually exclusive. I 
would use the JavaFX one for e.g., syntax coloration, and if I need 
something more advanced I would look at the alternatives. This is the 
same situation as other controls such as DatePicker or ColorPicker: they 
are sufficient for "basic" needs, more elaborated alternatives may exist 
in other projects.


    Martin

Re: Proposal: RichTextArea Control (Incubator)

[Pedro Duque Vieira]

Hi,

I agree with what others are saying that perhaps creating and adding this
control is not a priority now for the JavaFX team.
In an ideal world where the JavaFX team had more resources to implement
things (like the team JavaFX had at the time of JavaFX 8 and before), this
would make sense. Given the limited resources, IMHO time would be perhaps
better spent elsewhere, adding much needed features to the core of JavaFX.
Things that can only be implemented by the developers working on the SDK.
Given this is a control that can be implemented by library developers and
given there are already third parties that provide this I don't think
creating this should be a priority.

Providing more hooks for developers to extend javafx functionality (to
counteract the fact that JavaFX is so closed up for extension),
implementing missing features in the JavaFX SDK, perhaps even things that
would make it easier for library developers to implement a RichTextArea,
would IMHO be more of a priority.

My 2 cents,

Thanks, kind regards,


-- 
Pedro Duque Vieira - https://www.pixelduke.com


Sem
vírus.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

Hi,

Interesting remarks.

> Hello,
>
> >> A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
>
> It uses the standard JavaFX VirtualFlow API and and does not need to work
> with reactive streams. RichtextFX depends on several long unmaintained
> libs: ReactFX (last commit 8 years ago), WellBehavedFX (last commit 6 years
> ago), UndoFX (last commit 3 years ago). To say it's actively maintained is
> a big exaggeration.
>

What do you think about our Rich Text Area project?
https://github.com/gluonhq/rich-text-area
I hear your concerns about depending on unmaintained libs, and it is one of
my own primary filter criteria to either use or not use software

>> What (if anything) is stopping a 3rd party from building a RichTextArea
> themselves?
>
> - The lack of a standard API. The Behavior API has been discussed for
> ages, but is still not implemented. Moreover, WellBehavedFX is literally a
> rejected JEP/CSR implementation.
>
I agree a standard behavior API would be helpful, but I don't think it is
needed for a third party control. I rather hope to see more third party
controls being developed using different approaches, so that the community
in general gets more experience with the different approaches, as that
would give useful feedback on an approach to standardize it in OpenJFX. You
know how it goes with projects in OpenJDK: once something is in, it has to
be maintained and supported for a very long time and it is really hard to
change it.


> - The closedness of JavaFX in general. All internals are explicitly
> private and final. A few simple examples. The date picker popup uses a
> private API to calculate its width based on text size, but you're forbidden
> to do the same thing. All i18n resources are not exported, you're forbidden
> to use them to create a context menu. You're not encouraging 3rd party
> libs, you're going in the opposite direction (for the sake of stability of
> course).
>
Valid point. And it should be addressed. I wasn't part of the discussions
where the decision was to close as much as possible, but I believe the idea
was to close almost everything, and then to open API's when needed, after
it was clear that opening the API would benefit the ecosystem without
giving up stability. This happened a number of times in the past years, but
I agree there is still much room for improvements.


> - The JavaFX community is very small. The "tens of thousands of
> developers" you talk about don't exist. Even famous projects are poorly
> maintained or not maintained at all, including ControlsFX and ScenicView.
> You have fewer features -> you have fewer users/market share -> you have
> less promotion -> you have fewer committers -> you have fewer features.
> It's that simple.
>
I think this is partly true, but it's more nuanced I believe. I am aware of
a number of real large JavaFX projects, with many developers working on
them. Most of these large projects are developed after closed walls, with
lots of duplicated code that could go in a library. For the ecosystem as a
whole, that's not good. It would be much better if we were in a situation
where individual developers or companies would create and maintain
libraries that would then be used in those big projects. For non-technical
reasons, this is unfortunately not the case.


> - There's literally no docs about creating new controls. Even Skin API is
> badly documented. You can only learn from existing control libs.
>
This is a very valid concern. And I believe it is more important for us
(openjfx-dev) to fix this, rather than do everything ourselves in the
OpenJFX core. We need to encourage developers to create new controls, and
provide more documentation, tutorials etc,... In the early days of JavaFX,
there was a big team (it would now be called devrel I guess) that was
working on this, helping developers and the ecosystem, but we know what
happened next. That gap is not yet filled, and this is the price we are
still paying for it.


> This particular feature would be a HUGE step forward. I'm really glad to
> see it. Hopefully it won't get buried under a bunch of pointless abstract
> discussions like the CSS theme CSR. Just get some feedback and implement it
> the way you want. It's a million times better than doing nothing.
>
Well, it's not that we're doing nothing. We are doing a number of things:

1. inside openjfx: keep it working. This should not be underestimated. With
the fast and not always logical changes in platforms/OS code, there is lots
of code under the hood that needs to be maintained and improved. A number
of people on this list are extremely active on this, and spending lots of
time on it. Unfortunately, this doesn't make headlines as the result of the
hard work is often that "existing things keep working". Apart from keeping
it working, I feel we are moving forward and making gradual progress. Over
the past year, I saw more people contributing to OpenJFX and 

Re: Proposal: RichTextArea Control (Incubator)

[mkpaz]

Hello,

>> A 3rd party control, RichTextFX already exists -- what is this new 
proposal adding that RichTextFX does not have?


It uses the standard JavaFX VirtualFlow API and and does not need to 
work with reactive streams. RichtextFX depends on several long 
unmaintained libs: ReactFX (last commit 8 years ago), WellBehavedFX 
(last commit 6 years ago), UndoFX (last commit 3 years ago). To say it's 
actively maintained is a big exaggeration.


>> What (if anything) is stopping a 3rd party from building a 
RichTextArea themselves?


- The lack of a standard API. The Behavior API has been discussed for 
ages, but is still not implemented. Moreover, WellBehavedFX is literally 
a rejected JEP/CSR implementation.
- The closedness of JavaFX in general. All internals are explicitly 
private and final. A few simple examples. The date picker popup uses a 
private API to calculate its width based on text size, but you're 
forbidden to do the same thing. All i18n resources are not exported, 
you're forbidden to use them to create a context menu. You're not 
encouraging 3rd party libs, you're going in the opposite direction (for 
the sake of stability of course).
- The JavaFX community is very small. The "tens of thousands of 
developers" you talk about don't exist. Even famous projects are poorly 
maintained or not maintained at all, including ControlsFX and 
ScenicView. You have fewer features -> you have fewer users/market share 
-> you have less promotion -> you have fewer committers -> you have 
fewer features. It's that simple.
- There's literally no docs about creating new controls. Even Skin API 
is badly documented. You can only learn from existing control libs.


This particular feature would be a HUGE step forward. I'm really glad to 
see it. Hopefully it won't get buried under a bunch of pointless 
abstract discussions like the CSS theme CSR. Just get some feedback and 
implement it the way you want. It's a million times better than doing 
nothing.


On 23/02/2024 14.45, Johan Vos wrote:

I fully agree with John on this.

A RichTextArea is something that can "easily" be developed outside 
OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our 
(Gluon) RichTextArea at

https://github.com/gluonhq/rich-text-area

In the past, we clearly said that this was not a focus for OpenJFX.

There are a huge amount of outstanding issues in JBS that can only be 
fixed in the OpenJFX "core". Developers (of custom 
components/controls) rely on the core OpenJFX development to address 
those issues. That is what this group (the openjfx-dev list) is 
supposed to do.


I highly encourage developers to create custom components and 
controls, but not as part of OpenJFX. As others noted as well, we have 
many other things to fix that can only be fixed in OpenJFX, and that 
is where the priorities of OpenJFX should be, imho.


- Johan

On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx 
 wrote:


Hi,

Far be it from me to tell the FX team what it should do, I am
still wondering the following:

- A 3rd party control, RichTextFX already exists -- what is this
new proposal adding that RichTextFX does not have?
- What (if anything) is stopping a 3rd party from building a
RichTextArea themselves?

In other words, I think the FX team ought to focus on
**facilitating** the building of complex controls like
RichTextArea, by identifying gaps in the current Control API that
is **stopping** 3rd parties from doing this themselves in the same
integrated manner as a "native" FX control.

Enabling thousands or tens of thousand of developers to build more
complicated controls seems to me like a much better investment
than what I think will be a significant investment in one of the
most complex controls imaginable.  RichTextFX was actively
developed over a 4 year period, with 45 contributors and over 1400
commits (for comparison, JavaFX had 250 commits in the past
year).  If it will be significantly less complicated, then what
does it offer over RichTextFX?

--John

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control,
RichTextArea, intended to bridge the functional gap with Swing
and its StyledEditorKit/JEditorPane.  The main design goal is to
provide a control that is complete enough to be useful out-of-the
box, as well as open to extension by the application developers.

This is a complex feature with a large API surface that would be
nearly impossible to get right the first time, even after an
extensive review.  We are, therefore, introducing this in an
incubating module, *javafx.incubator.richtext*. This will allow
us to evolve the API in future releases without the strict
compatibility constraints that other JavaFX modules have.

Please take a look at the proposal [0], a list of discussion
points [1], and 

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

On Wed, Feb 21, 2024 at 7:09 PM Andy Goryachev 
wrote:

> Dear JavaFX developers:
>
...

> Sincerely,
>
> Your friendly JavaFX development team.
>

Not sure I understand that signature. I believe everyone on this list is
part of the JavaFX development team.

Re: Proposal: RichTextArea Control (Incubator)

[Johan Vos]

I fully agree with John on this.

A RichTextArea is something that can "easily" be developed outside OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our (Gluon)
RichTextArea at
https://github.com/gluonhq/rich-text-area

In the past, we clearly said that this was not a focus for OpenJFX.

There are a huge amount of outstanding issues in JBS that can only be fixed
in the OpenJFX "core". Developers (of custom components/controls) rely on
the core OpenJFX development to address those issues. That is what this
group (the openjfx-dev list) is supposed to do.

I highly encourage developers to create custom components and controls, but
not as part of OpenJFX. As others noted as well, we have many other things
to fix that can only be fixed in OpenJFX, and that is where the priorities
of OpenJFX should be, imho.

- Johan

On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx 
wrote:

> Hi,
>
> Far be it from me to tell the FX team what it should do, I am still
> wondering the following:
>
> - A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
> - What (if anything) is stopping a 3rd party from building a RichTextArea
> themselves?
>
> In other words, I think the FX team ought to focus on **facilitating** the
> building of complex controls like RichTextArea, by identifying gaps in the
> current Control API that is **stopping** 3rd parties from doing this
> themselves in the same integrated manner as a "native" FX control.
>
> Enabling thousands or tens of thousand of developers to build more
> complicated controls seems to me like a much better investment than what I
> think will be a significant investment in one of the most complex controls
> imaginable.  RichTextFX was actively developed over a 4 year period, with
> 45 contributors and over 1400 commits (for comparison, JavaFX had 250
> commits in the past year).  If it will be significantly less complicated,
> then what does it offer over RichTextFX?
>
> --John
> On 21/02/2024 19:07, Andy Goryachev wrote:
>
> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
>
> [1] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [2] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [3] Draft Pull Request for API comments and feedback:
> https://github.com/openjdk/jfx/pull/1374
>
> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [5] Missing APIs related to rich text control:
> https://bugs.openjdk.org/browse/JDK-8300569
>
>
>
>

Re: [External] : Re: Proposal: RichTextArea Control (Incubator)

[Daniel Peintner]

Dear Andy, others,

Thank you for your feedback. Yes, having a one-line TextArea, mocking up a
TextField, that contains a longer text with some sub-strings being able to
style is enough for my use-case.

Anyhow, I agree with others that having the possibility to "style" parts of
other controls like Label, TextField, etc would be very astonishing. This
might introduce a lot of complexity, I guess.

Having said that, this would offer a unique selling point and go beyond
what other external libraries did. Anyhow, this would most probably
facilitate such work in the future.

Best,

-- Daniel


On Thu, Feb 22, 2024 at 5:29 PM Andy Goryachev 
wrote:

> Dear Daniel:
>
>
>
> Thank you for your kind words!
>
>
>
> Re: StyledTextArea/TextField.
>
>
>
> This is a very interesting question.  It is definitely out of scope right
> now, but we can certainly talk about it.
>
>
>
> One major difference between the new control and the regular
> TextField/TextArea is that we add a separate rich text model, while
> TextField/Area expose a String 'text' property.  We could think of using
> the same model, or constructing some kind of StyledDocument, but in any
> case it won't be a drop-in replacement for TextField/TextArea.
>
>
>
> The other aspect is the visuals.  Whereas a StyledTextArea might require
> the same kinds of surrounding toolbars and controls to function as a
> useable editor (font, style, color, etc.), how would a StyledTextField look?
>
>
>
> At the same time, it is possible to easily configure RichTextArea to look
> like a styled text area or one-line styled text field.  It is also possible
> that another use case exists which requires a dedicated control?
>
>
>
>
>
> Re: spell checker.
>
>
>
> Yes, there is a way to add a "squiggly line", see here:
>
>
> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md#creating-a-paragraph
>
>
>
> At this moment, this functionality is not a part of any standard model,
> but is certainly possible.
>
>
>
> It might be also possible to add a similar functionality to the regular
> TextField/TextArea using public APIs, simply by adding a "squiggly" line
> shape over the standard control.  Just a thought.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *Daniel Peintner 
> *Date: *Thursday, February 22, 2024 at 03:07
> *To: *Andy Goryachev 
> *Cc: *openjfx-dev@openjdk.org 
> *Subject: *[External] : Re: Proposal: RichTextArea Control (Incubator)
>
> Hi Andy, others,
>
>
>
> I highly appreciate and welcome the effort of a built-in RichTextArea .
>
>
>
> A question that popped up in my mind is whether this work might include
> work in the area of *rich* TextField also? Probably it is out of scope.
> Anyhow, JavaFX Textfields are used in even more areas in UI controls like
> in tables etc and having the possibility to style them would be similarly
> convincing.
>
>
>
> As you might know, some alternative *external* solutions like RichTextFX
> do provide next to StyleClassedTextArea also StyleClassedTextField.
>
>
>
> Anyway, thank you very very much for the continuous development.
>
>
>
> Sincerely,
>
>
>
> -- Daniel
>
>
>
> P.S: Maybe just one line about the use case I have in mind. We do offer
> (based on RichTextFX) the ability to do "spell checking" on text (like you
> know from all word processors). A red underline shows a possible mistake
> and a ContextMenu offers fixes. This red line is therefore needed for text
> in TextArea but also for text in TextField
>
>
>
>
>
> On Wed, Feb 21, 2024 at 7:07 PM Andy Goryachev 
> wrote:
>
> Dear JavaFX developers:
>
>
>
> We would like to propose a new feature - rich text control, RichTextArea,
> intended to bridge the functional gap with Swing and its
> StyledEditorKit/JEditorPane.  The main design goal is to provide a control
> that is complete enough to be useful out-of-the box, as well as open to
> extension by the application developers.
>
>
>
> This is a complex feature with a large API surface that would be nearly
> impossible to get right the first time, even after an extensive review.  We
> are, therefore, introducing this in an incubating module,
> *javafx.incubator.richtext*.   This will allow us to evolve the API in
> future releases without the strict compatibility constraints that other
> JavaFX modules have.
>
>
>
> Please take a look at the proposal [0], a list of discussion points [1],
> and the API Specification (javadoc) [2]. While the proposed API is ready
> for review, it isn't complete nor set in stone. We are looking for
> feedback, and will update the proposal based on the suggestions we receive
> from the community.  We encourage you to comment either in the mailing
> list, or by leaving comments inline in a draft pull request [3].  For
> context, the links to the original RFE [4] and a list of missing APIs
> related to rich text [5] are provided below.
>
>
>
> Sincerely,
>
> Your friendly JavaFX development team.
>
>
>
>
>
> References
>
>
>
>
>
> 

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v11]

[Karthik P K]

On Thu, 22 Feb 2024 10:33:38 GMT, Karthik P K  wrote:

>> A valid concern about specific fonts, similar to 
>> https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815
>> 
>> What was the resolution there?  To use a hard-coded font based on the 
>> platform, or pick an available one from the list?
>
> The tests passes on Mac and Linux. The  failures I mentioned above were 
> because this branch was not upto date with the master and completely 
> unrelated to this PR.
> Im facing some issue with my Windows system. I will check in windows once it 
> is sorted and update the details here.

I have run the tests in Windows and did not see any failures.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1500338714