From john.hendrikx at gmail.com  Tue Jul  1 02:00:18 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 1 Jul 2025 04:00:18 +0200
Subject: JFX25: TableView + col.setMaxWidth() now clipping column headers
In-Reply-To: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
References: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
Message-ID: <979949ea-6e1f-407d-b72a-0cb80ce0e078@gmail.com>

Hi Cormac,

That definitely looks like a bug.? Setting the maximum constraint should
not have that effect.? The documentation describes what you'd expect and
does not allude to the odd side effects you are seeing.

Some work was done recently on the resizing of table columns, perhaps a
regression was introduced there.

--John

On 29/06/2025 01:41, Cormac Redmond wrote:
> Hi,
>
> While testing JFX25 (on Windows), previously perfectly-sized column
> sizes are now "too small", hiding parts of the column header.
>
> Code to reproduce:
>
> public class TableViewColSizeBug extends Application {
>
> ? ? @Override
> ? ? public void start(Stage stage) {
> ? ? ? ? TableView<String> table = new TableView<>();
> ? ? ? ? TableColumn<String, String> col1 = new TableColumn<>();
> ? ? ? ? col1.setGraphic(new Text("Column One (... ...)"));
>
> ? ? ? ?
> table.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN);
>
> ? ? ? ? // Setting a max width causes a "too small" column size
> ? ? ? ? col1.setMaxWidth(500); // Note large param
>
> ? ? ? ? table.getColumns().addAll(col1, new TableColumn<>("Col 2"),
> new TableColumn<>("Col 3"), new TableColumn<>("Col 4"), new
> TableColumn<>("Col 5"));
> ? ? ? ? stage.setScene(new Scene(new VBox(table), 600, 200));
> ? ? ? ? stage.show();
> ? ? }
>
> ? ? public static void main(String[] args) {
> ? ? ? ? launch();
> ? ? }
> }
>
> ?
> Notice the clear difference between JFX24 and JFX25 behaviour. If you
> do NOT setMaxWidth, there is no issue. For some reason, calling
> setMaxWidth, no matter how large the param, triggers this.
>
> JFX25 (as per code above, setting a column Text graphic),?col width
> too small:
> image.png
>
> JFX25 using "new TableColumn<>("Column One (... ...)")", instead of
> setting a Text graphic; col width also too small:
> image.png
>
> JFX25 when you do NOT do setMaxWidth(...),?looks fine:
>
> image.png
> JFX24 (in all instances, looks fine):
> image.png
>
> Is this a bug?
>
>
> Kind Regards,
> Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11186 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9817 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10133 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13967 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0007.png>

From lkostyra at openjdk.org  Tue Jul  1 10:56:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 1 Jul 2025 10:56:53 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
Message-ID: <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>

On Mon, 30 Jun 2025 16:58:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes; rewrite test to extend VisualTestBase
>
> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 118:
> 
>> 116:         Util.runAndWait(() -> {
>> 117:             Color color = getColor(STAGE_SIZE / 2, STAGE_SIZE / 2);
>> 118:             assertColorEquals(Color.LIGHTGREEN, color, TOLERANCE);
> 
> I wonder if this implementation is a reliable test: the stage in question may be overlapped by another window somewhere in the corner, right?
> 
> What would be a reliable test?  Strictly speaking, we must check every pixel in the scene, though I wonder if checking each pixel in a grid (maybe 20 x 20, since we don't expect any reasonable window to be less than that) should be enough?

The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2177242492

From angorya at openjdk.org  Tue Jul  1 15:13:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Jul 2025 15:13:49 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
Message-ID: <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>

On Tue, 1 Jul 2025 10:54:16 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 118:
>> 
>>> 116:         Util.runAndWait(() -> {
>>> 117:             Color color = getColor(STAGE_SIZE / 2, STAGE_SIZE / 2);
>>> 118:             assertColorEquals(Color.LIGHTGREEN, color, TOLERANCE);
>> 
>> I wonder if this implementation is a reliable test: the stage in question may be overlapped by another window somewhere in the corner, right?
>> 
>> What would be a reliable test?  Strictly speaking, we must check every pixel in the scene, though I wonder if checking each pixel in a grid (maybe 20 x 20, since we don't expect any reasonable window to be less than that) should be enough?
>
> The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.

I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2177865033

From andy.goryachev at oracle.com  Tue Jul  1 16:40:17 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 16:40:17 +0000
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage
 via Software Renderer
In-Reply-To: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
Message-ID: <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

The devil is in detail, but I like this proposal very much, especially if most of the machinery is already there.

How would it work if one does enable the software pipeline?  Or the headless platform?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Friday, June 27, 2025 at 03:15
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

Hi list,

I'm exploring whether there is interest in exposing a (Canvas) GraphicsContext-like interface for WritableImage backed by the existing software rendering pipeline.  Currently, JavaFX offers two main choices for drawing and pixel manipulation, each with different trade-offs:

- Canvas provides rich drawing primitives via GraphicsContext, but offers no direct pixel access?requiring costly GPU readbacks (e.g., snapshot()).
- WritableImage, on the other hand, allows direct pixel manipulation via PixelReader/PixelWriter, but has no built-in support for drawing operations like shapes, fills, or blending.

My proposal would combine the strengths of both:

- Expose drawing operations (shapes, fills, etc.) for WritableImage
- Direct access to image data before or after rendering without GPU readbacks / snapshots
- Reuse of JavaFX?s software rendering stack (SWGraphics, PiscesRenderer, etc.) without activating the software pipeline globally

I?ve successfully tested this approach in a non-modular FX application by accessing internal APIs from com.sun.prism.sw. With minor adjustments (--add-exports), it may also work in modular environments.

Work needed to support this as a public API might include:

- Creating a new GraphicsContext-like interface ("DrawingContext" ?)
- Exposing a method on WritableImage to obtain such a context
- Optionally, refactoring Canvas' GraphicsContext to implement this new interface (method signatures are likely compatible)
- Implementing the new interface on top of the software renderer

See the end of the post for a working example (assuming you place the code in the "com.sun.prism.sw" package and deal with the module restrictions).  Note that you do not need to enable the software pipeline (and you don't want to either, as the whole point is to remain GPU accelerated but have software renderer backed drawing primitives for images).

Any feedback appreciated!

--John

package com.sun.prism.sw;

import com.sun.glass.ui.Screen;

import com.sun.glass.utils.NativeLibLoader;

import com.sun.pisces.JavaSurface;

import com.sun.pisces.PiscesRenderer;

import com.sun.pisces.RendererBase;

import com.sun.prism.paint.Color;

import java.nio.IntBuffer;

import javafx.application.Application;

import javafx.scene.Scene;

import javafx.scene.image.ImageView;

import javafx.scene.image.PixelWriter;

import javafx.scene.image.WritableImage;

import javafx.scene.layout.StackPane;

import javafx.stage.Stage;

public class SWRendererExample {

static {

NativeLibLoader.loadLibrary("prism_sw");

}

public static void main(String[] args) {

Application.launch(App.class);

}

public static class App extends Application {

@Override

public void start(Stage primaryStage) {

WritableImage writableImage = createImageWithSWPipeline();

Scene scene = new Scene(new StackPane(new ImageView(writableImage)));

primaryStage.setScene(scene);

primaryStage.show();

}

}

public static WritableImage createImageWithSWPipeline() {

int width = 400;

int height = 300;

SWResourceFactory resourceFactory = new SWResourceFactory(Screen.getMainScreen());

SWRTTexture texture = new SWRTTexture(resourceFactory, width, height);

SWContext swContext = new SWContext(resourceFactory);

// Set up a surface to draw on and create the renderer:

int[] backingArray = new int[width * height];

IntBuffer pixelBuffer = IntBuffer.wrap(backingArray);

JavaSurface surface = new JavaSurface(backingArray, RendererBase.TYPE_INT_ARGB_PRE, width, height);

PiscesRenderer renderer = new PiscesRenderer(surface);

// Create SWGraphics for drawing (software renderer)

SWGraphics swGraphics = new SWGraphics(texture, swContext, renderer);

swGraphics.clear(Color.WHITE);

swGraphics.setPaint(Color.BLUE);

swGraphics.fillRect(50, 50, 100, 100);

swGraphics.setPaint(Color.RED);

swGraphics.fillEllipse(75, 75, 10, 20);

// Take the result and place it in a writable image:

WritableImage writableImage = new WritableImage(width, height);

PixelWriter pw = writableImage.getPixelWriter();

pw.setPixels(0, 0, width, height, javafx.scene.image.PixelFormat.getIntArgbPreInstance(), pixelBuffer.array(), 0, width);

return writableImage;

}

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/af9f1db9/attachment-0001.htm>

From john.hendrikx at gmail.com  Tue Jul  1 17:36:27 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 1 Jul 2025 19:36:27 +0200
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage
 via Software Renderer
In-Reply-To: <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
 <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>

If you enable the software pipeline, that would not change anything,
apart from the libraries already being loaded and the software renderer
being used more often. The renderer used in the example would be
independent and so it would not interfere.

As far as the headless platform goes, if it allows for the software
pipeline to be loaded, then this code should function as well as the
Pisces renderer used here is pure Java.? A mock Screen may need to be
provided.? I'm not well-versed currently in the specifics of the
headless platform.? Perhaps somebody working on it could comment?

--John


On 01/07/2025 18:40, Andy Goryachev wrote:
>
> The devil is in detail, but I like this proposal very much, especially
> if most of the machinery is already there.?
>
> ?
>
> How would it work if one does enable the software pipeline?? Or the
> headless platform?
>
> ?
>
> -andy
>
> ?
>
> ?
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Friday, June 27, 2025 at 03:15
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Proposal: Exposing a GraphicsContext-like API for
> WritableImage via Software Renderer
>
> Hi list,
>
> I'm exploring whether there is interest in exposing a (Canvas)
> GraphicsContext-like interface for WritableImage backed by the
> existing software rendering pipeline.? Currently, JavaFX offers two
> main choices?for drawing and pixel manipulation, each with different
> trade-offs:
>
> - Canvas provides rich drawing primitives via GraphicsContext, but
> offers no direct pixel access?requiring costly GPU readbacks (e.g.,
> snapshot()).
> - WritableImage, on the other hand, allows direct pixel manipulation
> via PixelReader/PixelWriter, but has no built-in support for drawing
> operations like shapes, fills, or blending.
>
> My proposal would combine the strengths of both:
>
> - Expose drawing operations (shapes, fills, etc.) for WritableImage?
> - Direct access to image data before or after rendering without GPU
> readbacks / snapshots
> - Reuse of JavaFX?s software rendering stack (SWGraphics,
> PiscesRenderer, etc.) without activating the software pipeline globally
>
> I?ve successfully tested this approach in a non-modular FX application
> by accessing internal APIs from com.sun.prism.sw. With minor
> adjustments (--add-exports), it may also work in modular environments.
>
> Work needed to support this as a public API might include:
>
> - Creating a new GraphicsContext-like interface ("DrawingContext" ?)
> - Exposing a method on WritableImage to obtain such a context
> - Optionally, refactoring Canvas' GraphicsContext to implement this
> new interface (method signatures are likely compatible)
> - Implementing the new interface on top of the software renderer
>
> See the end of the post for?a working example (assuming you place the
> code in the "com.sun.prism.sw" package and deal with the module
> restrictions).? Note that you do not need to enable the software
> pipeline (and you don't want to either, as the whole point is to
> remain GPU accelerated but have software renderer backed drawing
> primitives for images).
>
> Any feedback appreciated!
>
> --John
>
> *package*com.sun.prism.sw;
>
> *import*com.sun.glass.ui.Screen;
>
> *import*com.sun.glass.utils.NativeLibLoader;
>
> *import*com.sun.pisces.JavaSurface;
>
> *import*com.sun.pisces.PiscesRenderer;
>
> *import*com.sun.pisces.RendererBase;
>
> *import*com.sun.prism.paint.Color;
>
> *import*java.nio.IntBuffer;
>
> *import*javafx.application.Application;
>
> *import*javafx.scene.Scene;
>
> *import*javafx.scene.image.ImageView;
>
> *import*javafx.scene.image.PixelWriter;
>
> *import*javafx.scene.image.WritableImage;
>
> *import*javafx.scene.layout.StackPane;
>
> *import*javafx.stage.Stage;
>
> *public**class*SWRendererExample {
>
> *static*{
>
> NativeLibLoader./loadLibrary/("prism_sw");
>
> }
>
> *public**static**void*main(String[] args) {
>
> Application./launch/(App.*class*);
>
> }
>
> *public**static**class*App *extends*Application {
>
> @Override
>
> *public**void*start(Stage primaryStage) {
>
> WritableImage writableImage = /createImageWithSWPipeline/();
>
> Scene scene = *new*Scene(*new*StackPane(*new*ImageView(writableImage)));
>
> primaryStage.setScene(scene);
>
> primaryStage.show();
>
> }
>
> }
>
> *public**static*WritableImage createImageWithSWPipeline() {
>
> *int*width = 400;
>
> *int*height = 300;
>
> SWResourceFactory resourceFactory =
> *new*SWResourceFactory(Screen./getMainScreen/());
>
> SWRTTexture texture = *new*SWRTTexture(resourceFactory, width, height);
>
> SWContext swContext = *new*SWContext(resourceFactory);
>
> // Set up a surface to draw on and create the renderer:
>
> *int*[] backingArray = *new**int*[width * height];
>
> IntBuffer pixelBuffer = IntBuffer./wrap/(backingArray);
>
> JavaSurface surface = *new*JavaSurface(backingArray,
> RendererBase.TYPE_INT_ARGB_PRE, width, height);
>
> PiscesRenderer renderer = *new*PiscesRenderer(surface);
>
> // Create SWGraphics for drawing (software renderer)
>
> SWGraphics swGraphics = *new*SWGraphics(texture, swContext, renderer);
>
> swGraphics.clear(Color.WHITE);
>
> swGraphics.setPaint(Color.BLUE);
>
> swGraphics.fillRect(50, 50, 100, 100);
>
> swGraphics.setPaint(Color.RED);
>
> swGraphics.fillEllipse(75, 75, 10, 20);
>
> // Take the result and place it in a writable image:
>
> WritableImage writableImage = *new*WritableImage(width, height);
>
> PixelWriter pw = writableImage.getPixelWriter();
>
> pw.setPixels(0, 0, width, height,
> javafx.scene.image.PixelFormat./getIntArgbPreInstance/(),
> pixelBuffer.array(), 0, width);
>
> *return*writableImage;
>
> }
>
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/ced6ba53/attachment-0001.htm>

From andy.goryachev at oracle.com  Tue Jul  1 17:48:40 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 17:48:40 +0000
Subject: [External] : Re: Proposal: Exposing a GraphicsContext-like API
 for WritableImage via Software Renderer
In-Reply-To: <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
 <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>
Message-ID: <CY8PR10MB7265A761E545C4A8006D3314E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

There is currently a POC PR https://github.com/openjdk/jfx/pull/1836 for headless, so it might be relatively easy to check.

-andy

From: John Hendrikx <john.hendrikx at gmail.com>
Date: Tuesday, July 1, 2025 at 10:36
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

If you enable the software pipeline, that would not change anything, apart from the libraries already being loaded and the software renderer being used more often. The renderer used in the example would be independent and so it would not interfere.

As far as the headless platform goes, if it allows for the software pipeline to be loaded, then this code should function as well as the Pisces renderer used here is pure Java.  A mock Screen may need to be provided.  I'm not well-versed currently in the specifics of the headless platform.  Perhaps somebody working on it could comment?

--John


On 01/07/2025 18:40, Andy Goryachev wrote:
The devil is in detail, but I like this proposal very much, especially if most of the machinery is already there.

How would it work if one does enable the software pipeline?  Or the headless platform?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Friday, June 27, 2025 at 03:15
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

Hi list,

I'm exploring whether there is interest in exposing a (Canvas) GraphicsContext-like interface for WritableImage backed by the existing software rendering pipeline.  Currently, JavaFX offers two main choices for drawing and pixel manipulation, each with different trade-offs:

- Canvas provides rich drawing primitives via GraphicsContext, but offers no direct pixel access?requiring costly GPU readbacks (e.g., snapshot()).
- WritableImage, on the other hand, allows direct pixel manipulation via PixelReader/PixelWriter, but has no built-in support for drawing operations like shapes, fills, or blending.

My proposal would combine the strengths of both:

- Expose drawing operations (shapes, fills, etc.) for WritableImage
- Direct access to image data before or after rendering without GPU readbacks / snapshots
- Reuse of JavaFX?s software rendering stack (SWGraphics, PiscesRenderer, etc.) without activating the software pipeline globally

I?ve successfully tested this approach in a non-modular FX application by accessing internal APIs from com.sun.prism.sw. With minor adjustments (--add-exports), it may also work in modular environments.

Work needed to support this as a public API might include:

- Creating a new GraphicsContext-like interface ("DrawingContext" ?)
- Exposing a method on WritableImage to obtain such a context
- Optionally, refactoring Canvas' GraphicsContext to implement this new interface (method signatures are likely compatible)
- Implementing the new interface on top of the software renderer

See the end of the post for a working example (assuming you place the code in the "com.sun.prism.sw" package and deal with the module restrictions).  Note that you do not need to enable the software pipeline (and you don't want to either, as the whole point is to remain GPU accelerated but have software renderer backed drawing primitives for images).

Any feedback appreciated!

--John

package com.sun.prism.sw;

import com.sun.glass.ui.Screen;

import com.sun.glass.utils.NativeLibLoader;

import com.sun.pisces.JavaSurface;

import com.sun.pisces.PiscesRenderer;

import com.sun.pisces.RendererBase;

import com.sun.prism.paint.Color;

import java.nio.IntBuffer;

import javafx.application.Application;

import javafx.scene.Scene;

import javafx.scene.image.ImageView;

import javafx.scene.image.PixelWriter;

import javafx.scene.image.WritableImage;

import javafx.scene.layout.StackPane;

import javafx.stage.Stage;

public class SWRendererExample {

static {

NativeLibLoader.loadLibrary("prism_sw");

}

public static void main(String[] args) {

Application.launch(App.class);

}

public static class App extends Application {

@Override

public void start(Stage primaryStage) {

WritableImage writableImage = createImageWithSWPipeline();

Scene scene = new Scene(new StackPane(new ImageView(writableImage)));

primaryStage.setScene(scene);

primaryStage.show();

}

}

public static WritableImage createImageWithSWPipeline() {

int width = 400;

int height = 300;

SWResourceFactory resourceFactory = new SWResourceFactory(Screen.getMainScreen());

SWRTTexture texture = new SWRTTexture(resourceFactory, width, height);

SWContext swContext = new SWContext(resourceFactory);

// Set up a surface to draw on and create the renderer:

int[] backingArray = new int[width * height];

IntBuffer pixelBuffer = IntBuffer.wrap(backingArray);

JavaSurface surface = new JavaSurface(backingArray, RendererBase.TYPE_INT_ARGB_PRE, width, height);

PiscesRenderer renderer = new PiscesRenderer(surface);

// Create SWGraphics for drawing (software renderer)

SWGraphics swGraphics = new SWGraphics(texture, swContext, renderer);

swGraphics.clear(Color.WHITE);

swGraphics.setPaint(Color.BLUE);

swGraphics.fillRect(50, 50, 100, 100);

swGraphics.setPaint(Color.RED);

swGraphics.fillEllipse(75, 75, 10, 20);

// Take the result and place it in a writable image:

WritableImage writableImage = new WritableImage(width, height);

PixelWriter pw = writableImage.getPixelWriter();

pw.setPixels(0, 0, width, height, javafx.scene.image.PixelFormat.getIntArgbPreInstance(), pixelBuffer.array(), 0, width);

return writableImage;

}

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/5ab1ee84/attachment-0001.htm>

From andy.goryachev at oracle.com  Tue Jul  1 21:43:14 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 21:43:14 +0000
Subject: FW: [External] : Re: JFX25: TableView + col.setMaxWidth() now
 clipping column headers
In-Reply-To: <CY8PR10MB72653E6F289133BF76FB42AEE541A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
 <CY8PR10MB726586A13E859913DCD45BD6E546A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaDwVYS8QM--Baqhnpf2asRzw_Ba4R_-P_aScRJizyCS0Q@mail.gmail.com>
 <CY8PR10MB72657F7D8093F6C43F18922EE546A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaAwNoD_9WPYmDnzYgjNb5a1a=GDqj2gBq5M75uxiwvuZQ@mail.gmail.com>
 <CY8PR10MB72653E6F289133BF76FB42AEE541A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CY8PR10MB7265DF775A11AA580E711D33E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

Didn't realize I replied to a direct message.  Re-posting to the mailing list.

-andy



From: Andy Goryachev <andy.goryachev at oracle.com>
Date: Tuesday, July 1, 2025 at 09:25
To: Cormac Redmond <credmond at certak.com>
Subject: Re: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
You and John are right: this is a bug.  Setting the max width should not impact the distribution of extra space, unless the column hits the constraint.

Created https://bugs.openjdk.org/browse/JDK-8361210

Thanks!
-andy


From: Cormac Redmond <credmond at certak.com>
Date: Monday, June 30, 2025 at 19:35
To: Andy Goryachev <andy.goryachev at oracle.com>
Subject: Re: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
Thanks for the details, Andy.

Generally speaking, it seems like confusing behaviour (to anyone not reading this thread), that a column header is visible normally, but suddenly isn't when specifying a maximum size. It's counter-intuitive.

And the value of that maximum size seems to have no bearing on the (small) size of the column. It's always the same: just slightly too small.

It's not a big deal for me, I'm thinking of the community.



Kind Regards,
Cormac

On Mon, 30 Jun 2025 at 23:44, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
Found the change: https://bugs.openjdk.org/browse/JDK-8299753 - I thought it went in earlier.

The resizing logic does indeed consider maximum widths (when the available space exceeds the sum of preferred widths), so the behavior is as designed.  The unexpected part comes from the fact that the rest of the columns have the maximum sizes of 5000, and that is what we see, as it distributes less space to the first column.

I would suggest to set preferred widths.  Don't know whether your application supports restoring UI settings between sessions, but that's what I do in my projects: https://github.com/andy-goryachev/AppFramework<https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework__;!!ACWV5N9M2RV99hQ!IFuNYGKCo_TFdOe3pZK4gs3O7aIckRW7RFESr_0V4PJXeWeQVExP735zJO2VoYxcIxDtAaYaIQJZQ5XGqvDM9g$>

-andy




From: Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Monday, June 30, 2025 at 14:54
To: Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
Hi,

Well, it's not making much sense to me.

If you set a preferred width that's "too small", it's coming up with some other size (probably the 80 you're talking about):

// col1.setPrefWidth(500);
col1.setPrefWidth(25);

[cid:ii_197c3342932cb971f165]

...but if you specify a max, the pref width is suddenly honoured:

col1.setMaxWidth(500);
col1.setPrefWidth(25);

[cid:ii_197c3342932cb971f166]

The above is JFX25.

I think I noticed this oddity in my application because I had prefWidths that were probably too small -- but JFX24 still made them fit (unbeknownst to me). JFX25 doesn't appear to do that though, whatever has changed there.

Thanks for the tips. Not sure if this is worth worrying about or not, but definitely the behaviour has changed.




Kind Regards,
Cormac

On Mon, 30 Jun 2025 at 22:29, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
When using constrained resize policy, it is better to set the preferred widths explicitly.  Otherwise, the initial distribution is a function of default preferred / maximum sizes which are, if I recall correctly, are 80 and 5000 respectively.

You can see that the first column has shrunk because of the change in the max width (5000 -> 500).  I am not entirely sure why setting the max width of one column has such an effect, it is certainly not used for initiali allocation except to limit the width, which is not the case in the screenshots provided.

What happens when you set the preferred width for the columns?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Saturday, June 28, 2025 at 16:42
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: JFX25: TableView + col.setMaxWidth() now clipping column headers
Hi,

While testing JFX25 (on Windows), previously perfectly-sized column sizes are now "too small", hiding parts of the column header.

Code to reproduce:

public class TableViewColSizeBug extends Application {

    @Override
    public void start(Stage stage) {
        TableView<String> table = new TableView<>();
        TableColumn<String, String> col1 = new TableColumn<>();
        col1.setGraphic(new Text("Column One (... ...)"));

        table.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN);

        // Setting a max width causes a "too small" column size
        col1.setMaxWidth(500); // Note large param

        table.getColumns().addAll(col1, new TableColumn<>("Col 2"), new TableColumn<>("Col 3"), new TableColumn<>("Col 4"), new TableColumn<>("Col 5"));
        stage.setScene(new Scene(new VBox(table), 600, 200));
        stage.show();
    }

    public static void main(String[] args) {
        launch();
    }
}


Notice the clear difference between JFX24 and JFX25 behaviour. If you do NOT setMaxWidth, there is no issue. For some reason, calling setMaxWidth, no matter how large the param, triggers this.

JFX25 (as per code above, setting a column Text graphic), col width too small:
[cid:ii_197c3342932cb971f162]

JFX25 using "new TableColumn<>("Column One (... ...)")", instead of setting a Text graphic; col width also too small:
[cid:ii_197c3342932cb971f163]

JFX25 when you do NOT do setMaxWidth(...), looks fine:

[cid:ii_197c3342932cb971f164]
JFX24 (in all instances, looks fine):
[cid:ii_197c3342932cb971f161]

Is this a bug?


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13967 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11186 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9817 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10133 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2827 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2194 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0011.png>

From lkostyra at openjdk.org  Wed Jul  2 06:49:51 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 06:49:51 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
 <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
Message-ID: <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>

On Tue, 1 Jul 2025 15:11:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.
>
> I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?

Turning the scene to undecorated would just make the math easier, without having to count in the window decorations which almost certainly would be of different color.

As for the margin thing, I had to do a bit of history searching and I came back with this old PR: https://github.com/openjdk/jfx/pull/1242

I think when writing the above my blurry memory had to recall to one of the attempts at solving this which involved just skipping the 1px margin of the Stage on HiDPI systems. I agree, it should be fine just going through the entire Stage.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2179255898

From arapte at openjdk.org  Wed Jul  2 07:53:24 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Jul 2025 07:53:24 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  add @Override

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/67e06ae8..e8ac354a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=04-05

  Stats: 6 lines in 5 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Wed Jul  2 08:05:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Jul 2025 08:05:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v5]
In-Reply-To: <MFFkpcOBfFAetVA2JzTjK2IkS90knxGVYHiMEn9QoYA=.08eef53b-b245-45df-92cd-9e811cc67456@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <VqFhUWTkkd70tv7Qn-Ezs4UG7PDzXPnvYtQWVWzVUa8=.bbc9b0cf-b21b-45ef-a543-2f54aacd7858@github.com>
 <MFFkpcOBfFAetVA2JzTjK2IkS90knxGVYHiMEn9QoYA=.08eef53b-b245-45df-92cd-9e811cc67456@github.com>
Message-ID: <H5pMCLpZNJ5N9tp-gmSdl2tsOrncafH7EKGB_g2tQKc=.8bfbda68-f8f7-4b67-a884-352453c9b5bf@github.com>

On Mon, 30 Jun 2025 15:46:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The method createStockShader(String) of type DummyResourceFactory should be tagged with `@Override` since it actually overrides a superinterface method	DummyResourceFactory.java	Java Problem	/graphics/src/main/java/com/sun/prism/null3d	line 132

Thank you, added `@Override` annotation to mentioned methods.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3026869510

From lkostyra at openjdk.org  Wed Jul  2 11:06:45 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 11:06:45 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
 <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
 <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>
Message-ID: <_cT7hbhKBnVB7igGurT_tYoomS-V3xJOmzxsgvA9IKE=.e1d7930f-de8a-467e-8b6c-e04ab105a7be@github.com>

On Wed, 2 Jul 2025 06:47:22 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?
>
> Turning the scene to undecorated would just make the math easier, without having to count in the window decorations which almost certainly would be of different color.
> 
> As for the margin thing, I had to do a bit of history searching and I came back with this old PR: https://github.com/openjdk/jfx/pull/1242
> 
> I think when writing the above my blurry memory recalled one of the attempts at solving this which involved just skipping the 1px margin of the Stage on HiDPI systems. I agree, it should be fine just going through the entire Stage.

Actually a small correction, using `VisualTestBase` already assumes the Stage we get is undecorated. So no changes need to be made there.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2179768493

From lkostyra at openjdk.org  Wed Jul  2 12:58:30 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 12:58:30 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Expand check for whether Stage is on top

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/2df8fe80..32a97c24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=03-04

  Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1804.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1804/head:pull/1804

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

From angorya at openjdk.org  Wed Jul  2 14:53:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 14:53:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <oyGtZYsfnpCUMLUw_-bFad9V9WrsG9dUH6p0pgSL3BM=.0307ea9f-af8e-4f7e-808f-9a4235fa531d@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

Still getting the exception loading "msl/jfxshaders.metallib".  I am running in eclipse, so perhaps the eclipse project files need to include some added paths?  I've got a few of them in the workspace:
![Screenshot 2025-07-02 at 07 50 49](https://github.com/user-attachments/assets/c32df879-e4f7-4e12-a130-9822069774e2)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3028174357

From angorya at openjdk.org  Wed Jul  2 14:56:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 14:56:49 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

Is `mtl` a good name for the `prism.order` property?  Should it be `metal`?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3028184471

From nlisker at openjdk.org  Wed Jul  2 15:00:54 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 2 Jul 2025 15:00:54 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
Message-ID: <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>

On Wed, 2 Jul 2025 14:54:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Is `mtl` a good name for the `prism.order` property? Should it be `metal`?

"mtl" is sometimes used a short for "material", which has overlapping context here. I'd prefer the explicit "metal".

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3028202402

From angorya at openjdk.org  Wed Jul  2 18:58:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 18:58:28 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v5]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <GKvp6VYy_w5bIZaXbPjeDjJ2FgXTjKnUVXr1ug8gzEA=.99c5b224-1002-4f69-9dc6-6f2713576124@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - api
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - seems to work
 - ... and 49 more: https://git.openjdk.org/jfx/compare/0270847b...c3842c03

-------------

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=04
  Stats: 589 lines in 12 files changed: 559 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  2 21:01:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 21:01:50 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
Message-ID: <3763giTKhF2iIZSdebEXkvXLwyapCfPr0r9VzTI61dU=.f0b63724-a6c3-4385-a1dd-442c4c84a086@github.com>

On Wed, 2 Jul 2025 12:58:30 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand check for whether Stage is on top

Looks good!  Left some minor suggestions.

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 67:

> 65:     static final Color SCENE_COLOR = Color.LIGHTGREEN;
> 66: 
> 67:     private Stage theStage = null;

null is unnecessary

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 99:

> 97:                 Platform.runLater(() -> {
> 98:                     theStage.setX(STAGE_X);
> 99:                     theStage.setY(STAGE_Y);

setting Stage (x,y) coordinates in runLater makes the window jump.
it's probably better to move LL98-99 before runLater, to L96

with the robot disabled, the test fails with expected

org.opentest4j.AssertionFailedError: Event received latch timed out! Stage most probably did not have focus after showing. Some tests might fail because of this. If that is the case, try re-running the tests with '--no-daemon' flag in Gradle. ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 124:

> 122:             PixelReader captureReader = capture.getPixelReader();
> 123:             for (int x = 0; x < STAGE_SIZE; ++x) {
> 124:                 for (int y = 0; y < STAGE_SIZE; ++y) {

I was thinking of testing ever 5th or 10th pixel, but this code is fast enough.
If I quickly click on some window underneath the test window, the test correctly fails with 

org.opentest4j.AssertionFailedError: expected:rgba(144,238,144,255) but was:rgba(234,234,234,255)

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 137:

> 135:         assertTrue(
> 136:             eventReceivedLatch.await(TIMEOUT, TimeUnit.MILLISECONDS),
> 137:             "Event received latch timed out! Stage most probably did not have focus after showing. Some tests might fail because of this. " +

I'd suggest to replace "Event received latch timed out!", or re-phrase completely, maybe

"The Stage did not received the key stroke generated by Robot.  This might happen if the stage did not receive focus.  Some tests might fail because of this.
Try re-running the tests with '--no-daemon' flag in Gradle.".

or something along these lines.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-2980590440
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180956422
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180948401
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180961162
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180954317

From jvos at openjdk.org  Wed Jul  2 21:51:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 2 Jul 2025 21:51:25 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource from
 jar
Message-ID: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>

After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.

The 2 changes I made are:
1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

-------------

Commit messages:
 - Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks

Changes: https://git.openjdk.org/jfx/pull/1839/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357714
  Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1839.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1839/head:pull/1839

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

From mfox at openjdk.org  Wed Jul  2 22:47:43 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 2 Jul 2025 22:47:43 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
Message-ID: <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>

On Wed, 2 Jul 2025 12:58:30 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand check for whether Stage is on top

I'm having an issue with this test. I can't get it to fail on my Windows 11 box but I can get other tests to fail due to focus issues.

I'm working on a system keyboard test (see attached patch for a pared down version). On my Windows 11 box the focus does not go to the stage unless I invoke the Robot mouse-click workaround. If I don't use that workaround the key event is going to the terminal window instead of the stage.

In that same environment the StageFocusTest in this PR always succeeds. I've never seen it fail. I've run these tests from both a Cygwin terminal and a MSYS2 MINGW terminal using bash and sh and StageFocusTest always passes.

I also notice that even when my test case fails the window is still on top, it just doesn't have focus. So the color testing in this PR seems unnecessary (?) Are you seeing cases where the stage is below other windows when it shows up?

[ShortcutKeyboardTest.patch](https://github.com/user-attachments/files/21026158/ShortcutKeyboardTest.patch)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3029547784

From maw at weichi.com  Wed Jul  2 23:03:08 2025
From: maw at weichi.com (maw at weichi.com)
Date: Wed, 2 Jul 2025 19:03:08 -0400
Subject: Debugger
Message-ID: <009a01dbeba5$7ad19b90$7074d2b0$@weichi.com>

The Debugger is private. How is it to be used?

 

Marvin Wolfthal

maw at weichi.com <mailto:maw at weichi.com> 

http://www.marvinwolfthal.com <http://www.marvinwolfthal.com> 

https://www.youtube.com/@marvinwolfthal6402

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250702/c98376a3/attachment-0001.htm>

From fkirmaier at openjdk.org  Thu Jul  3 07:06:46 2025
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 3 Jul 2025 07:06:46 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
References: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
Message-ID: <VvjXnaH3Ph60VU7SgFS3TJ9LKiIBSEEnSfg4HnwlF0c=.ef0051e9-bbb7-4309-a746-d5421fd0e050@github.com>

On Wed, 18 Jun 2025 20:58:20 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX.
> 
> The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method.
> 
> The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus.
> 
> I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors.
> 
> Co-Author: @FlorianKirmaier

The model we are trying to have here is quite simple.

**Background**
When a Window/Toolkit gets focused, it defines which menus should be shown.
This is done by removing the old menus, and adding their own.
This is basically, what the OS does, when you switch from Application A to B, just inside one process.

Actually, we only wanted to make the JavaFX menu work when Swing/AWT was started first.
But as far as we see, our solution also makes all combinations work.

**Test**
What is definitely missing, which we will add, are unit tests.
We have already investigated - there is an Apple Command line API, which allows us to read out which menus are currently shown. We will add some unit-tests, which should provide confidence that this is working reliably.

I hope these tests will improve the confidence, that this solution is correct and maintainable.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-3031120580

From jvos at openjdk.org  Thu Jul  3 07:22:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 3 Jul 2025 07:22:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <ICTnrwPyaIi1N5QekEztm8WftwuTZeL4yaiIg8Ux3GA=.1172d5d3-ed3f-40c6-aa12-29589c15b320@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

@sashamatveev can you review this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3031162932

From lkostyra at openjdk.org  Thu Jul  3 12:36:44 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 3 Jul 2025 12:36:44 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
 <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>
Message-ID: <FvYGsRycG7hEIi48a-aXsl_lqWteM4YocpeEjjRYIgI=.5f06e9ca-ce0d-4dd9-afd5-db7c158b24db@github.com>

On Wed, 2 Jul 2025 22:45:16 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I'm having an issue with this test. I can't get it to fail on my Windows 11 box but I can get other tests to fail due to focus issues.

I started to see this problem as well while working on [JDK-8359899 (the Stage.isFocused discrepancy)](https://bugs.openjdk.org/browse/JDK-8359899). I have a suspicion that switching to VisualTestBase caused some sort of difference - VisualTestBase creates new Stages separately and doesn't take into account the primary Stage that you would get via overriding Application.start(). I noticed your test does not use VisualTestBase so it might be it.

I have not looked into a solution yet outside of the obvious - reverting to not using VisualTestBase. I will get that figured out very soon with Andy's review suggestions.

> I also notice that even when my test case fails the window is still on top, it just doesn't have focus. So the color testing in this PR seems unnecessary (?) Are you seeing cases where the stage is below other windows when it shows up?

I did have situations where the Stage would appear under currently active window, sometimes even under the terminal window that runs the test.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3032101631

From arapte at openjdk.org  Thu Jul  3 12:53:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Jul 2025 12:53:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
 <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>
Message-ID: <VXqN-4Un8QY9FdoYbMF8NQDzTqB3Zve_2_f-DssjpWI=.44367ef1-0b4c-4c74-a565-132b3885ff1f@github.com>

On Wed, 2 Jul 2025 14:58:34 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > Is `mtl` a good name for the `prism.order` property? Should it be `metal`?
> 
> "mtl" is sometimes used a short for "material", which has overlapping context here. I'd prefer the explicit "metal".

mtl was chose because
- It aligns with our existing abbreviated names for pipelines like d3d, es2, sw
- The metal library also uses 'MTL' as prefix all metal library types like MTLDevice, MTLCommandQueue, MTLCommandBuffer and more..

I think It would feel relevant in the context of `-Dprism.order`

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3032155165

From angorya at openjdk.org  Thu Jul  3 14:43:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 14:43:48 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 812:

> 810:             unsigned int blockSize = -1;
> 811:             if (isRandomAccess) {
> 812:                 blockSize = locatorStream->GetCallbacks()->ReadBlock(pos, size);

would it make sense to declare a local variable for `locatorStream->GetCallbacks()` ?
or do we assume the compiler is smart enough to do that?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2182969956

From angorya at openjdk.org  Thu Jul  3 14:58:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 14:58:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <xUBJLrM0xK-tsWqvgYH7j-eETRKwUJbYf3WorASAu10=.8a030e7a-e935-4774-9d3e-36caae739ce8@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Would it be possible to come up with a system test?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3032579681

From angorya at openjdk.org  Thu Jul  3 19:30:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 19:30:13 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
Message-ID: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>

> Adding missing APIs related to styling the highlights with CSS:
> 
> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
> 
> 
> 
> Adds methods to the `RichParagraph.Builder`:
> 
> 
>         /**
>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addWavyUnderline(int start, int length, String ... css) {
> 
> 
> 
>         /**
>          * Adds a highlight with the specified style name(s).
>          * Use translucent colors to enable multiple highlights in the same region of text.
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addHighlight(int start, int length, String ... css) {
> 
> 
> 
> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
> 
> 
>     /**
>      * Adds a highlight of the given color to the specified range within the last paragraph,
>      * with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
> 
> 
>     /**
>      * Adds a wavy underline (typically used as a spell checker indicator)
>      * to the specified range within the last paragraph, with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {

Andy Goryachev 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 four additional commits since the last revision:

 - Merge branch 'master' into 8355774.css
 - Merge remote-tracking branch 'origin/master' into 8355774.css
 - tab
 - css

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1802/files
  - new: https://git.openjdk.org/jfx/pull/1802/files/5f1e084c..15617920

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=01-02

  Stats: 9379 lines in 126 files changed: 8187 ins; 753 del; 439 mod
  Patch: https://git.openjdk.org/jfx/pull/1802.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1802/head:pull/1802

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

From credmond at certak.com  Thu Jul  3 21:24:12 2025
From: credmond at certak.com (Cormac Redmond)
Date: Thu, 3 Jul 2025 22:24:12 +0100
Subject: Inconsistent drawing/layouts of Dialogs & show()/showAndWait()
 differences
Message-ID: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>

Hi,

I have noticed inconsistent and confusing size/layout behaviour with
Dialogs when changing min width or height (after shown).

The behaviour depends on whether changing min width/height on the Stage, or
the DialogPane itself, and whether show() or showAndWait() is used.

In summary:

   1. Set Stage mins + show()
      - no bug
   2.  Set Stage mins + showAndWait()
      - improper layout: background applies only to label (i.e., size
      before re-size), button wrong position, re-sizing window fixes the problem
   3. 3 Set DialogPane mins + show()
      - min sizes are ignored, button is visible, until it comes into
      focus, and then the button disappears, you can find it if you
resize window
      close to the mins set
   4. 4 Set DialogPane mins + showAndWait()
      - no bug

It's happening in JFX23/24/25. Note, these may seem trivial/fixable, or you
may ask "why would you do that?", but there are reasons I won't clutter the
mail with.

Anyway, it's best presented with a set of examples and code.

Re points 1 and 2 above, exact same code, except red is showAndWait() and
green is show():

[image: image.png]

Obviously, they should behave the same. Then slightly resize the red one:

[image: image.png]


Examples 3 and 4 above -- again, same code. Purple is show(), yellow is
showAndWait().

[image: image.png]

After you close the yellow dialog:

[image: image.png]

They should be the same size from the outset.



public class DialogBug extends Dialog<Boolean> {

    public DialogBug(final String s, boolean flip) {
        setTitle("Bug");
        setResizable(true);

        final DialogPane dp = getDialogPane();
        dp.setStyle(s);
        dp.getButtonTypes().add(ButtonType.CLOSE);
        dp.setContent(new Label("Content"));

        // Setting stage size causes the bug
        setOnShown(e -> {

            if (flip) {
                // Set stage sizes
                Stage st = (Stage) dp.getScene().getWindow();
                st.setMinHeight(260);
                st.setMinWidth(360);
            } else {
                // Set dialog sizes: note buttons disappear when you resize
                dp.setMinHeight(260);
                dp.setMinWidth(360);
            }
        });
    }

    public static class BugApp extends Application {
        @Override
        public void start(final Stage st) throws Exception {

            final boolean FLIP_ME = true; // make true for other bug

            if (FLIP_ME) {
                // Note: bug doesn't happen when using show() only. Stage
is fully green on show.
                new DialogBug("-fx-background-color: green;", true).show();
// NO BUG

                // showAndWait presents the bug; background not fully
drawn, button shifts on re-size
                new DialogBug("-fx-background-color: red;",
true).showAndWait(); // BUG
            } else {
                // A different type of issue: two different sizes and
button behaviour
                // Notice:
                // - same dialogs, different sizes
                // - how button in purple dialog shifts when yellow dialog
pane is closed
                new DialogBug("-fx-background-color: purple;",
false).show(); // BUG

                new DialogBug("-fx-background-color: yellow;",
false).showAndWait(); // NO BUG
            }
        }
    }
}

Thoughts?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12215 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 8224 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12750 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2688 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0007.png>

From almatvee at openjdk.org  Thu Jul  3 21:30:45 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 21:30:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

modules/javafx.media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm line 331:

> 329:         CJavaInputStreamCallbacks *callbacks = new (nothrow) CJavaInputStreamCallbacks();
> 330:         jobject jConnectionHolder = CLocator::CreateConnectionHolder(env, jLocator);
> 331:         if (callbacks == NULL) {

Missing `NULL` check for  `jConnectionHolder`. `if (callbacks == NULL || jConnectionHolder == NULL)`

If `callbacks` is not `NULL` it needs to be deleted.

modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:

> 804: 
> 805:         NSMutableData* readData = nil;
> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();

`URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183766995
PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183772092

From almatvee at openjdk.org  Thu Jul  3 21:30:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 21:30:46 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>
Message-ID: <TDfr-nwqSStm5j5TMAewjXxqEcaiLIxFPMtKEzNqmJQ=.1e6541e5-7c9c-4623-803a-3806b86132df@github.com>

On Thu, 3 Jul 2025 14:41:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 812:
> 
>> 810:             unsigned int blockSize = -1;
>> 811:             if (isRandomAccess) {
>> 812:                 blockSize = locatorStream->GetCallbacks()->ReadBlock(pos, size);
> 
> would it make sense to declare a local variable for `locatorStream->GetCallbacks()` ?
> or do we assume the compiler is smart enough to do that?

Not sure, but do not see a need from performance point view.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183777438

From almatvee at openjdk.org  Thu Jul  3 22:02:44 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 22:02:44 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <1PD28xQVXVKCptksMzq11_kSJiMn75fk73Ns1xzMSkc=.f01c6758-7d26-406f-9522-5d02103d3053@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Looks good overall.
- Undo changed in `AVFMediaPlayer.mm`. There is no need for it and this code will never execute.
- Add NULL pointer check and deletion of `callbacks` if not NULL.
- Change title for issue to something like `MediaPlayer and AudioClip can crash when playing media files over "jar" and "jrt" protocols via OSXPlatform`.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3033789612

From kizune at openjdk.org  Thu Jul  3 22:21:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 3 Jul 2025 22:21:52 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
Message-ID: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>

- Copyright year update;
- Introduce new function requestNodeAttribute and refactor code to use it;
- Fix some typos;
- Enable new code to handle TabPages since TabGroup was implemented;

-------------

Commit messages:
 - 8361379: [macos] Refactor accessibility code to retrieve attribute by name

Changes: https://git.openjdk.org/jfx/pull/1840/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361379
  Stats: 94 lines in 3 files changed: 12 ins; 54 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1840.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1840/head:pull/1840

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

From lkostyra at openjdk.org  Fri Jul  4 06:59:24 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Jul 2025 06:59:24 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:

 - Parameterize StageFocusTest
   
   This is to check if Stage showing works also for Stages other than the
   primary Stage provided by Application.start()
 - Review fixes; revert using VisualTestBase

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/32a97c24..56cdcf4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=04-05

  Stats: 122 lines in 1 file changed: 84 ins; 1 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1804.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1804/head:pull/1804

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

From lkostyra at openjdk.org  Fri Jul  4 07:09:42 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Jul 2025 07:09:42 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
Message-ID: <vImh9FTffbdOVXrswCGNjYAR_nfBzy3K5rpSiYn__mA=.c6ea1e44-d268-4bca-8d90-db7384a95546@github.com>

On Fri, 4 Jul 2025 06:59:24 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Parameterize StageFocusTest
>    
>    This is to check if Stage showing works also for Stages other than the
>    primary Stage provided by Application.start()
>  - Review fixes; revert using VisualTestBase

I did a couple of extra changes in addition to the regular fixes:
- `extend VisualTestBase` was removed, it was indeed the cause of the test always passing. The "Windows forbids granting focus" scenario seems to only happen when we try and show the Stage provided by `Application.start()`
- Tests are now parameterized and check both the primaryStage delivered by `Application.start()` as well as a separately created Stage. Figured it might be worth testing as well, since it seems to behave slightly differently and can affect other test.

I did notice this morning that on a fresh system start, the test _can_ pass even with `--daemon` gradle flag. This happens when it is the first invocation of Gradle that run - then the used Gradle daemon instance is a child of current Terminal process (which is a foreground process) which makes Windows treat it as a foreground process as well and grant focus to its children. The most reliable way I found of reproducing this and getting the test to fail on my Windows 11 box (also has to be done after calling `gradle --stop`):
- Run one build using `gradle --daemon`
- Close the Terminal window - that will cut the daemon's association with the Terminal and make Windows treat it as a background process
- Re-open the terminal and re-run the tests using `gradle --daemon`

For me the test then fails when checking the primary Stage delivered by `Application.start()` at the keystroke part of the test.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3034768336

From arapte at openjdk.org  Fri Jul  4 12:44:44 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 4 Jul 2025 12:44:44 GMT
Subject: RFR: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place
In-Reply-To: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
References: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
Message-ID: <0kxn0ZVHFA6ei6s8LXjhCU5_WrCkAAltL0A_cp2zirc=.80b960e7-100e-4de7-9e4b-989c7d4c642e@github.com>

On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot.
> More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753)
> 
> In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time.
> 
> This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps).
> 
> ----
> 
> * The remote desktop for Robot is enabled by default on GnomeShell 47+
> * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46)
> * The key handling might still have bugs.
> * The main goal is to add this new functionality.  If there are small issues that can't be solved right away,  I will prefer to fix them in follow up fixes.

LGTM, 
Verified that no test fail on ubuntu 24.04. and changes are very similar to that of JDK.

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1834#pullrequestreview-2987075508

From jvos at openjdk.org  Fri Jul  4 13:06:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 4 Jul 2025 13:06:46 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
Message-ID: <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>

On Thu, 3 Jul 2025 21:23:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:
> 
>> 804: 
>> 805:         NSMutableData* readData = nil;
>> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();
> 
> `URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?

In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2185323239

From arapte at openjdk.org  Sat Jul  5 01:38:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sat, 5 Jul 2025 01:38:42 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <LPatJEveDfni7JkIykb-nJgpfOXemS6ckvfWU8azBbg=.bba0abe4-7e1a-4f66-8fa7-31c3e1741abc@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

> Still getting the exception loading "msl/jfxshaders.metallib". I am running in eclipse, so perhaps the eclipse project files need to include some added paths? I've got a few of them in the workspace: ![Screenshot 2025-07-02 at 07 50 49](https://private-user-images.githubusercontent.com/107069028/461579606-c32df879-e4f7-4e12-a130-9822069774e2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTE2NzgyNTIsIm5iZiI6MTc1MTY3Nzk1MiwicGF0aCI6Ii8xMDcwNjkwMjgvNDYxNTc5NjA2LWMzMmRmODc5LWU0ZjctNGUxMi1hMTMwLTk4MjIwNjk3NzRlMi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwNzA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDcwNVQwMTEyMzJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mNDYxN2I3ZDYzNWI2MDdkMjNmZjA1M2U4ZmM2MGQxMzMzZjE4MGI3MjNkMmY4ZjMwYzk2MGI3N2EwOGY4ZDcyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.r1DObrQTjY4fEy54axEqTL
 DZ0rU3n4wQ7D82-bAaQgg)

It should use the file from build directory:
`build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl/msl/jfxshaders.metallib`

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3037627009

From duke at openjdk.org  Sat Jul  5 02:34:47 2025
From: duke at openjdk.org (Glavo)
Date: Sat, 5 Jul 2025 02:34:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

Unfortunately, this commit caused our app to behave abnormally :(

I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3037733509

From jhendrikx at openjdk.org  Sat Jul  5 04:59:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 5 Jul 2025 04:59:48 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
 <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
Message-ID: <Rpi3XkwnJZ2bdn0C07RiFgpAxn2rRis21_avBHoj760=.2078c96c-e731-4757-bbd2-08be0c44f207@github.com>

On Sat, 5 Jul 2025 02:32:18 GMT, Glavo <duke at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
> 
> I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

@Glavo I'd be interested in what problem you're running into (maybe before/after description?).  Perhaps there is a bug in the fix.  It's also possible you inadvertently have been relying on the behavior where content bias is sometimes ignored, which was a bug.  All FX containers always respect content bias.  In that case the only solution is to modify your layout a bit.  Let me know if I can be of help.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3038078858

From duke at openjdk.org  Sat Jul  5 06:20:46 2025
From: duke at openjdk.org (Glavo)
Date: Sat, 5 Jul 2025 06:20:46 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
 <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
Message-ID: <zCJp5i9wDlmwwa_N2AM5fcO7cayBB9_UstxrB1o56No=.8968d0d1-d4ea-46ff-acfa-728ff42c194f@github.com>

On Sat, 5 Jul 2025 02:32:18 GMT, Glavo <duke at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
> 
> I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

> @Glavo I'd be interested in what problem you're running into (maybe before/after description?). Perhaps there is a bug in the fix. It's also possible you inadvertently have been relying on the behavior where content bias is sometimes ignored, which was a bug. All FX containers always respect content bias. In that case the only solution is to modify your layout a bit. Let me know if I can be of help.

We encountered this problem. The content of this page (excluding the title bar) is a `BorderPane`, and the red box is the content of its center, a `FlowPane`.

![image](https://github.com/user-attachments/assets/fa373e33-c5b8-40aa-83ae-64fc71733641)

In OpenJFX 25+9 and earlier, the height of this `FlowPane` was 280 pixels, but since 25+10, its height has grown to 576 pixels, so that the interface layout is broken.

![image](https://github.com/user-attachments/assets/dfff7048-32fa-42e5-8dd7-ab3925a5d9a5)

It is not difficult for us to solve this problem. Wrapping this `FlowPane` in a `ScrollPane` will restore its height to normal. However, I still don?t understand the specific reason behind it.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3038246961

From jhendrikx at openjdk.org  Sun Jul  6 08:27:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 08:27:48 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <9VSGw5vdgdpv29g0FMbxsZGNZZ9xNs_4O6942pD_WP0=.5d7345a7-6475-4bf2-9568-155a1c60f350@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

The BorderPane shares some of the calculations with VBox, so it's possible it is a bug.  This small program can reproduce the issue:


.main .button {
  -fx-pref-width: 12em;
  -fx-pref-height: 12em;
}



package app;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.Label;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.FlowPane;
import javafx.stage.Stage;

public class LayoutBugDemo extends Application {

    @Override
    public void start(Stage stage) {
        BorderPane borderPane = new BorderPane();
        FlowPane flowPane = new FlowPane();

        flowPane.getStyleClass().add("main");

        borderPane.setTop(new Label("Instance Name"));
        borderPane.setCenter(flowPane);

        flowPane.getChildren().addAll(
            new Button("Minecraft"),
            new Button("Forge"),
            new Button("NeoForge"),
            new Button("OptiFine"),
            new Button("Fabric"),
            new Button("Fabric API"),
            new Button("Quilt"),
            new Button("SQL/QFAPI")
        );

        borderPane.setBottom(new Button("Install"));

        Scene scene = new Scene(borderPane, 600, 400);

        scene.getStylesheets().add("styles.css");

        stage.setScene(scene);
        stage.setTitle("JavaFX Layout Bug Demo");
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }

}

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041190238

From jhendrikx at openjdk.org  Sun Jul  6 08:54:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 08:54:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <7EFgl4WC5omNH6lP-FlsfU5viJHgOY0mjqdY9j2wi2g=.3f2198b0-6417-41fd-ba33-8419927e01d0@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

I looked a bit further, and I think that the `getAreaHeight` function in `BorderPane` which forwards to `Region`'s `computeChildPrefAreaHeight` (which was given an extra parameter) is the culprit.  It's called with `fillWidth` set to `false` but calling it with `fillWidth` set to `true` seems to restore the old behavior.

The only troubling part of that fix however is that its counterpart (`getAreaWidth`) calls the corresponding region function for horizontal calculations with `fillHeight` set to `false` (which is why I used `false` for `fillWidth` in the height calculation as well).

I'll need to look more closely what is the correct fix here, as it seems to me that having vertical calculations use fill, but not horizontal calculations is also not what one would expect.   Creating an example where the FlowPane is laid out vertically and seeing how it behaves then may give a clue if that breaks in the same way (allocating too much width to it when used as the center of a border pane).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041218059

From jhendrikx at openjdk.org  Sun Jul  6 09:42:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 09:42:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <dhwhU-bNr7nMj7qjPPhnWYG_5nblSp10WHqQyHbCClc=.e64babb6-c4ab-4cc2-9e0d-7963ba7b7b89@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

It looks like when using a vertical flow pane, that the left-to-right version of the layout is also quite poor:

![image](https://github.com/user-attachments/assets/e4ee3e07-ad47-42b6-a51f-224314d17b42)

When I apply the same fix in `BorderPane` for the horizontal calculations, it becomes this:

![image](https://github.com/user-attachments/assets/92676801-e86c-4d21-bcab-a742abccf079)

Note how the flow pane now doesn't take an unreasonable amount of space anymore cutting the install button from view.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041253008

From jhendrikx at openjdk.org  Sun Jul  6 10:25:43 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 10:25:43 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <tGgyvJKAXSL0crqmnmLeJCbV6CAD5j55Qn01jzgdcIA=.62ee38ee-1683-417d-bbe1-d7c1f9c825d7@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

This would also address https://bugs.openjdk.org/browse/JDK-8092347

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-3041294377

From maw at weichi.com  Sun Jul  6 16:56:10 2025
From: maw at weichi.com (maw at weichi.com)
Date: Sun, 6 Jul 2025 12:56:10 -0400
Subject: Debugger
Message-ID: <007f01dbee96$e1011050$a30330f0$@weichi.com>

Why is WebEngine Debugger private?

 

Marvin Wolfthal

maw at weichi.com <mailto:maw at weichi.com> 

http://www.marvinwolfthal.com <http://www.marvinwolfthal.com> 

https://www.youtube.com/@marvinwolfthal6402

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250706/ae2e407d/attachment.htm>

From mstrauss at openjdk.org  Mon Jul  7 04:55:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
Message-ID: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>

Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

-------------

Commit messages:
 - javadoc
 - Added documentation
 - Add EventTarget.dispatchEvent(Event)
 - Capture (parent, delegate, dispatcher) in DelegatingEventDispatcher
 - Improved documentation, updated copyright headers
 - Merge branch 'master' into feature/focus-delegation
 - added getFocusDelegate(hoistingNode) parameter
 - Merge branch 'master' into feature/focus-delegation
 - Merge branch 'master' into feature/focus-delegation
 - added tests
 - ... and 3 more: https://git.openjdk.org/jfx/compare/0270847b...a9e6b8f8

Changes: https://git.openjdk.org/jfx/pull/1632/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343956
  Stats: 1045 lines in 16 files changed: 819 ins; 111 del; 115 mod
  Patch: https://git.openjdk.org/jfx/pull/1632.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1632/head:pull/1632

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

From mfox at openjdk.org  Mon Jul  7 04:55:22 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <2f1pzDot8o1VwXd8ZfpfyD5E9HP11NhzcD1ND-91ypU=.22544726-6aaf-4d7e-b3f3-927b244001e0@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

PopupWindows have to solve a similar problem; multiple nodes can receive key events and they all act as if they have focus. This gets (mildly) complicated when dealing with input methods. There may be multiple focused nodes but there can only be one caret so you have to have a mechanism to determine which node will respond to input method requests. You also have to determine when to enable and disable IM events at the OS level. Spinners have never dealt with input methods but ComboBoxes do.

I've submitted PR #1634 to get input methods working in popups. If you want input methods to work with focus delegation you would need to do similar bookkeeping.

I noticed that PopupWindows use EventRedirectors for forwarding messages. I didn't dig into the EventRedirector implementation but it is an existing class that seems to be tackling the same problem as this PR.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2470845326

From jhendrikx at openjdk.org  Mon Jul  7 04:55:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.

It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).

When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.

The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).

Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

> > It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?).
> 
> For what it's worth I am not a fan of using the term focus owner to refer to a focus delegate. The focusOwner of a Scene is the target of key events. The focus delegate of a ComboBox is the _second_ target of key events. Key events are sent to the ComboBox first and the delegate only receives the events that it doesn't consume. To me that's an important distinction.

I don't think the distinction quite holds.  Scene does not delegate all key events.  Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics.  Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.

However, I now think that "focus delegate" is indeed the better name for this.
 
> Presumably we would need a way of telling the focus scope node which sub-node hoisted the focus so it could select the correct delegate. But it's difficult to imagine a control that's trying to pass itself off as a monolithic entity having two internal TextFields. Wouldn't that require enabling keyboard traversal inside a monolithic control? What does that mean? I don't think this is a scenario we need to solve.

See my example in my reply to Michael, I think it may be worth having a few thoughts about.

Keep open IMHO.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2569018506
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646636802
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3027816893

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <1GwATw241DFoklYfHQNEXirmNyxicZ9v6qR_ALsczmU=.866ee8d3-0981-4dda-aa58-3595a2cfe523@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

@hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2637581233

From mfox at openjdk.org  Mon Jul  7 04:55:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

@hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.

> I don't think the distinction quite holds. Scene does not delegate all key events. Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics. Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.

What you describe is a common pattern in other UI toolkits but is not how JavaFX works. All key events are immediately fired at the Scene's focus owner and all processing happens within the resulting dispatch chain. The Scene provides a dispatcher that processes mnemonics during the capturing phase (early) and menu accelerators and navigation in the bubbling phase (late). The accelerators also cover the default dialog buttons.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2640728248
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2651763933

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.

Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.

Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2644856265

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
Message-ID: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>

On Sat, 8 Feb 2025 10:35:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
>> 
>> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
>> 
>> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
>> 
>> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
>> 
>> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.
>
>> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.
> 
> Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.
> 
> Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.

> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.

Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  

I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)

Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?

This can be achieved later, just interested in hearing your thoughts:
- A getter can later become a property
- A getter can later become part of an interface
- Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)

I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.

Again, I love this proposal, and would like to move it forward.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646187233

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
Message-ID: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>

On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> 
> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
> 
> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)

Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).


> Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?

It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.

That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.

But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646469169

From mfox at openjdk.org  Mon Jul  7 04:55:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
Message-ID: <8IoXCH_izHXmViBKO3RgiBOH_hnnpX2IV5T_0aPKDLc=.e23bb896-b809-44a8-97ca-7861d0a7586b@github.com>

On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?).

For what it's worth I am not a fan of using the term focus owner to refer to a focus delegate. The focusOwner of a Scene is the target of key events. The focus delegate of a ComboBox is the *second* target of key events. Key events are sent to the ComboBox first and the delegate only receives the events that it doesn't consume. To me that's an important distinction.

But really I just don't want to end up having a conversation about the focusOwner's focusOwner.

> But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

Presumably we would need a way of telling the focus scope node which sub-node hoisted the focus so it could select the correct delegate. But it's difficult to imagine a control that's trying to pass itself off as a monolithic entity having two internal TextFields. Wouldn't that require enabling keyboard traversal inside a monolithic control? What does that mean? I don't think this is a scenario we need to solve.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646621891

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
Message-ID: <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>

On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.
>> 
>> Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.
>> 
>> Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.
>
>> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> 
> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  
> 
> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> This can be achieved later, just interested in hearing your thoughts:
> - A getter can later become a property
> - A getter can later become part of an interface
> - Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)
> 
> I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.
> 
> Again, I love this proposal, and would like to move it forward.

> > > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> > 
> > 
> > Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
> > I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).

Perhaps the analogy does break down here.  I was thinking, if you could interact with a control on an inactive window, the control could decide if interacting with it should focus the window or not with the hoist focus flag.  However, that would presumably also means the Scene's focus owner shouldn't be changed (or be `null`).

> > Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.

I agree that focusOwner probably only works for well for Scene, although it could have been named focusDelegate and work quite well if there had been sufficient foresight :)

> That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.
> 
> But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

Why doesn't it just set the delegate to whatever hoisted focus in the first place?  A not entirely hypothetical `DateEntryControl` with 3 separate fields internally (with borders stripped) could have a day-month-year area (such controls were quite common before fancy date pickers).  Each of the subfields could set hoist focus.  Clicking on a specific subfield would put the cursor there, but focus the `DateEntryControl` as a whole.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646634700

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>
Message-ID: <Bp4rF908AIi8fTvpIbPwyRGqRGXI5-AdAGg7bkDHk1o=.007b0258-8a77-4bea-9d29-b7084b09c573@github.com>

On Tue, 11 Feb 2025 18:54:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > I don't think the distinction quite holds. Scene does not delegate all key events. Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics. Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.
> 
> What you describe is a common pattern in other UI toolkits but is not how JavaFX works. All key events are immediately fired at the Scene's focus owner and all processing happens within the resulting dispatch chain. The Scene provides a dispatcher that processes mnemonics during the capturing phase (early) and menu accelerators and navigation in the bubbling phase (late). The accelerators also cover the default dialog buttons.

But isn't that a distinction without a difference? Technically, you're right, all keys go to the focus owner.  In practice though, some never make it out the door.

Looks like I recalled wrong how menu keys are processed, surprisingly they can be blocked if you want.  I should have checked more closely :)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2652253774

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
Message-ID: <mxIrYsYnvKS4U15ZCfBNny-VTCJck59dfKtUXbfeatc=.78e7bcf8-fce5-4a48-ae1b-2285aada7126@github.com>

On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
>> 
>> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  
>> 
>> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
>> 
>> Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
>> 
>> This can be achieved later, just interested in hearing your thoughts:
>> - A getter can later become a property
>> - A getter can later become part of an interface
>> - Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)
>> 
>> I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.
>> 
>> Again, I love this proposal, and would like to move it forward.
>
>> > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
>> 
>> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
>> 
>> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).
> 
> 
>> Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.
> 
> That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.
> 
> But the proposed API doesn't seem to easily support this scenario. When I cl...

@mstr2 do you think it is worth pursuing this further?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2815089505

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>
Message-ID: <U8i0klMcmpQlB8DT_BcIqPZ_i-KSyN8Kq6G_sL9-u9o=.ee5ec36f-bb8f-49a4-86a5-2a958715818b@github.com>

On Sun, 9 Feb 2025 22:45:14 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Why doesn't it just set the delegate to whatever hoisted focus in the first place? A not entirely hypothetical `DateEntryControl` with 3 separate fields internally (with borders stripped) could have a day-month-year area (such controls were quite common before fancy date pickers). Each of the subfields could set hoist focus. Clicking on a specific subfield would put the cursor there, but focus the `DateEntryControl` as a whole.

I've added a parameter to `getFocusDelegate(Node hoistingNode)`, which indicates the node that hoisted the last focus request to the node on which `getFocusDelegate` is called. The hoisting node is not necessarily a focus delegate, it can be any descendant with the `hoistFocus` flag set.

When `getFocusDelegate(Node hoistingNode)` is called, the control can use the additional information to decide which of its children will be the focus delegate.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2834992966

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <xK4Qcn_iSCCMw4LTdBYiB21M7wBa9xJuQYikwz-9baA=.758c1cbf-329a-4f27-a2f8-4971229a2e96@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

Dispatching an event in the presence of focus delegation is slightly different, because it requires cooperation of the `Node` that is the event target. Previously, we would dispatch an event like this:

EventUtil.fireEvent(EventTarget, Event);


With focus delegation, we need to know what the final delegate will be, and we dispatch the event like this:

EventUtil.fireEvent(EventTarget firstTarget, EventTarget finalDelegate, Event event);


Of course, this is internal code that can only be called within the `Node` class (as only `Node` knows its final delegate). But we need a way for users to correctly dispatch an event without knowing `Node` internals. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) comes in handy here, so I've pulled that proposal into this feature.

Old code like `Event.fireEvent(EventTarget, Event)` is simply redefined to call `EventTarget.dispatchEvent(Event)`, ensuring that the overridden implementation `Node.dispatchEvent(Event)` is called. This ensures that events are always fired correctly.

Note that it is not enough to manually construct an event dispatch chain with `EventTarget.buildEventDispatchChain(EventDispatchChain)`, and call `EventDispatchChain.dispatchEvent(Event)` on it. This skips the very important step of setting the correct delegation target. I've added documentation to the existing method, clarifying that it should not be used by application developers. There is no reason to use it in any case, since we now have the `EventTarget.dispatchEvent(Event)` method instead.

This PR is now ready for review. We should finish the discussion of whether we want to have this feature in JavaFX. If we decide to go ahead, it is not required to migrate all controls to use focus delegation at the same time. This PR includes the `Spinner` control as an example, and more controls can be migrated step by step.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3043468451
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3043469192

From jvos at openjdk.org  Mon Jul  7 07:31:49 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:31:49 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <vmJ-yiSZRmURiVEXAjDZIRkOcd8NeYV9D49TkgehPmE=.56341777-cae9-4077-a8c5-378295c95b22@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <C5R8BspvBIL6n-E3yMIXGUX3jXqZgC6wlzyN1A4uedc=.2f4c50e3-b6d1-4c88-96d6-ceadac2ad487@github.com>
 <vmJ-yiSZRmURiVEXAjDZIRkOcd8NeYV9D49TkgehPmE=.56341777-cae9-4077-a8c5-378295c95b22@github.com>
Message-ID: <S358c-L69Dbga9Zr7MEpvLv0bQrDMxuiffaD9ZnqQHs=.dd742235-ac9c-43dc-b490-ae90ac645534@github.com>

On Fri, 27 Jun 2025 20:15:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There was a failing test, so it turns out there is an implicit contract that even if a resize is requested without different w/h parameters, at least the even should still be generated.
>
> should we either add a comment or clean up (or both) then?

I cleaned it up. Typically, I'm +1 on adding more comments in the code, but not everyone likes that. In this case, it would create a precedent where we would then add tons of comments mainly to document what the tests are doing (or expecting).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189215582

From jvos at openjdk.org  Mon Jul  7 07:36:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:36:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>

On Thu, 19 Jun 2025 22:33:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 36:
> 
>> 34:     private float alpha;
>> 35:     private Pixels icon;
>> 36:     private Cursor cursor;
> 
> The following fields are never used, other than assigning a value:
> * `ptr`
> * `resizable`
> * `visible`
> * `isFocusable`
> * `enabled`
> * `closed`
> * `bg_r`, `bg_g`, `bg_b`
> * `alpha`
> * `icon`
> * `cursor`

I had those since I think they might be useful "later", when we add more configuration options, or in case there are tests that rely on them. But I believe it is better indeed to remove them, and re-introduce them when needed.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189230076

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v5]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <ejMVO9gIiJtSRcyORKSF5SMRLs6FxgnKH0u4gmO_nhg=.379d7a00-9cc4-467f-b69d-5ad853ccc6f9@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process reviewer comments
  Remove unused code

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/743a3b7e..1962e05b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=03-04

  Stats: 23 lines in 2 files changed: 0 ins; 21 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <fzqMsh_QSmUWRf7tIEqfHQpV2LQfRFnUJTAhJK8J0Z0=.03df945c-911e-4028-bf52-65b581b0f7dc@github.com>

On Thu, 19 Jun 2025 22:13:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 293:
> 
>> 291:         if (button == MouseButton.BACK) return MouseEvent.BUTTON_BACK;
>> 292:         if (button == MouseButton.FORWARD) return MouseEvent.BUTTON_FORWARD;
>> 293:         return MouseEvent.BUTTON_NONE;
> 
> Use an expression to get compile-time exhaustiveness checks:
> Suggestion:
> 
>         return switch (button) {
>             case NONE -> MouseEvent.BUTTON_NONE;
>             case PRIMARY -> MouseEvent.BUTTON_LEFT;
>             case MIDDLE -> MouseEvent.BUTTON_OTHER;
>             case SECONDARY -> MouseEvent.BUTTON_RIGHT;
>             case BACK -> MouseEvent.BUTTON_BACK;
>             case FORWARD -> MouseEvent.BUTTON_FORWARD;
>         };

fixed

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189249816

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>
Message-ID: <Y4PmxwsbjI0WVkhPW6lI_wkw9MmPDJL6gDWgx9PP1rg=.e92db160-231a-4d4d-b293-a6808c77107a@github.com>

On Mon, 7 Jul 2025 07:34:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 36:
>> 
>>> 34:     private float alpha;
>>> 35:     private Pixels icon;
>>> 36:     private Cursor cursor;
>> 
>> The following fields are never used, other than assigning a value:
>> * `ptr`
>> * `resizable`
>> * `visible`
>> * `isFocusable`
>> * `enabled`
>> * `closed`
>> * `bg_r`, `bg_g`, `bg_b`
>> * `alpha`
>> * `icon`
>> * `cursor`
>
> I had those since I think they might be useful "later", when we add more configuration options, or in case there are tests that rely on them. But I believe it is better indeed to remove them, and re-introduce them when needed.

ptr and visible are used, I removed the others.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189246617

From jvos at openjdk.org  Mon Jul  7 08:37:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 08:37:47 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <qCq8Rqf8QWB1d0fmYyhkMY0Ur-sDe5qeuqI7lRaG2iY=.1f0fdec0-1646-47bd-aab5-8bba6c90e552@github.com>

On Thu, 19 Jun 2025 22:37:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 23:
> 
>> 21:     private final HeadlessWindowManager windowManager = new HeadlessWindowManager();
>> 22:     private Screen[] screens = null;
>> 23:     private HeadlessCursor cursor;
> 
> This field is not used in this class, other than assigning a value.

removed and changed createCursor method

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 268:
> 
>> 266:     }
>> 267: 
>> 268:     boolean setFullscreen(boolean full) {
> 
> None of the two callers use the return value of this method.

changed return type to void

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189366361
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189364588

From jvos at openjdk.org  Mon Jul  7 08:37:48 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 08:37:48 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <XW0BaMtZ2wyeMcW8luUevHA7j8PlUc9Xtho5VI6qQ-M=.1ef3d039-7723-4e46-9bd5-415155b8897c@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <XW0BaMtZ2wyeMcW8luUevHA7j8PlUc9Xtho5VI6qQ-M=.1ef3d039-7723-4e46-9bd5-415155b8897c@github.com>
Message-ID: <E9XugatAcSHZPqKWbeRhpt0v25YbmIMT0bNzrz0xMl0=.001d7689-97f0-4bec-8c26-2ec0578f761a@github.com>

On Fri, 27 Jun 2025 19:59:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java line 16:
>> 
>>> 14:     private Pixels pixels;
>>> 15: 
>>> 16:     private boolean imeEnabled;
>> 
>> The following fields are not read, but only assigned to in this class:
>> * `capabilities`
>> * `x`
>> * `y`
>> * `imeEnabled`
>> 
>> The field `parentPtr` is neither assigned nor read.
>
> x, y are read in View::getX/Y

removed capabilities and imeEnabled

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189369086

From jvos at openjdk.org  Mon Jul  7 09:06:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:06:08 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v6]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <S9UpXUTmaX0JbVUmWwnf77iTqvepKt3KA0I5iOsy9gY=.e79c5848-c51e-4f8c-af35-683dd23300c5@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  More reviewer processing

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/1962e05b..541d8e55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=04-05

  Stats: 10 lines in 3 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 09:15:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:15:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <nJpDhAjLTAfR8jPFVXz7O-FZzbNpXPt84PpayjZQwok=.71104f21-73d2-4a25-885a-1a3a1cdb4bc5@github.com>

On Fri, 27 Jun 2025 16:54:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 22:
> 
>> 20:     private final NestedRunnableProcessor processor = new NestedRunnableProcessor();
>> 21:     private final HeadlessWindowManager windowManager = new HeadlessWindowManager();
>> 22:     private Screen[] screens = null;
> 
> minor: no need to assign null, also L24

removed.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 41:
> 
>> 39:     @Override
>> 40:     protected void _invokeAndWait(Runnable runnable) {
>> 41:         throw new UnsupportedOperationException("Not supported yet.");
> 
> is there a follow-up bug for this, or the list of things to do?

I think it's best to keep this here, because in case there is somehow an invocation of this method, we want to be notified about it, and then come up with the most appropriate way to implement it.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 92:
> 
>> 90:     @Override
>> 91:     protected void staticCursor_setVisible(boolean visible) {
>> 92:         throw new UnsupportedOperationException("Not supported yet.");
> 
> should it be a no-op instead?  will cursor be supported at all?

There is a Headless Cursor, but the setVisible method doesn't seem to be used in any of the tests currently.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 179:
> 
>> 177:     public void getScreenCapture(int x, int y, int width, int height, int[] data, boolean scaleToFit) {
>> 178:         checkWindowFocused();
>> 179:         ((HeadlessWindow)activeWindow).getScreenCapture(x, y, width, height, data, scaleToFit);
> 
> maybe the `activeWindow` can be declared as `HeadlessWindow` to avoid casting

good idea, done

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189445871
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189447802
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189449818
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189454545

From jvos at openjdk.org  Mon Jul  7 09:15:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:15:47 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <_buCzuGyzQikonLUXoiIZfr_anIbzoCQ36U3i1voA-M=.bec1c6e5-f2e1-41ad-9240-07bccac1f68e@github.com>

On Thu, 19 Jun 2025 22:45:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 20:
> 
>> 18:     }
>> 19: 
>> 20:     void invokeLater(final Runnable r) {
> 
> The following methods are never used:
> * `invokeLater`
> * `runLater`
> * `invokeAndWait`
> * `stopProcessing`

invokeLater is used from HeadlessApplication
Others are removed now.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189444853

From jvos at openjdk.org  Mon Jul  7 09:18:44 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:18:44 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <-EWqPffHmp_NKfHW8QN5HmexgbxOnpNlT4BF8GMzYsY=.703b3cf5-a936-4922-8c90-4d5c2b75d77a@github.com>

On Fri, 27 Jun 2025 19:31:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 231:
> 
>> 229:         if (windows.isEmpty()) return null;
>> 230:         if (windows.size() == 1) return (HeadlessWindow)windows.get(0);
>> 231:         return (HeadlessWindow)windows.get(windows.size() -1);
> 
> call me old fashioned, but would a straightforward reverse `for` loop be better in this case?  no unnecessary memory allocations required.
> 
> here and in two methods below?

I'm not a fan of using Streams if it's not really needed, but in this case I think there might be benefits in eliminating the non-candidates in 1 statement -- I might be wrong though, didn't look yet at how this is compiled.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189460398

From jvos at openjdk.org  Mon Jul  7 09:22:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:22:45 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <5vBITMuRZ8SuWE2tVtR5s1qoA2yjmF2rf4c_S59H_CI=.0680f3f6-7b82-46a3-baea-761ac406b2af@github.com>

On Fri, 27 Jun 2025 20:00:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 19:
> 
>> 17: 
>> 18:     private static final AtomicInteger ptrCount = new AtomicInteger(0);
>> 19:     private long ptr;
> 
> since `ptr` is long, should `ptrCount` be `AtomicLong`?

it's more elegant indeed, so I changed it.
It's not really needed though, since contrary to native implementations, the pointer we return here is not a pointer to some memory, hence we don't need 64 bits. The method declaration for _createWindow requires a long though, so we need to return a long.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 316:
> 
>> 314:         int b = rgba & 0xFF;
>> 315: 
>> 316:         Color color = Color.color(
> 
> could use `Color::rgb(int,int,int,double)`;

done

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189466725
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189468946

From jvos at openjdk.org  Mon Jul  7 09:29:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:29:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process more reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/541d8e55..479a8149

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=05-06

  Stats: 44 lines in 4 files changed: 2 ins; 34 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 09:29:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:29:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <3jmKYq2h0Be_Qp02X2nJUAJatqxw98IHVQqfF12W3Ns=.33431bdc-bc82-43b9-ad5b-b441cc2d995a@github.com>

On Fri, 27 Jun 2025 20:19:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 329:
> 
>> 327:             for (int j = 0; j < width; j++) {
>> 328:                 int idx = i * width + j;
>> 329:                 int fidx = (y + i) * 1000 + x + j;
> 
> where does 1000 come from?

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 341:
> 
>> 339:         int offsetX = this.getX();
>> 340:         int offsetY = this.getY();
>> 341:         int stride = 1000;
> 
> same magic 1000 here

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 356:
> 
>> 354: 
>> 355:     void clearRect(int x0, int w0, int y0, int h0) {
>> 356:         int stride = 1000;
> 
> and here...

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477073
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477376
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477514

From jpereda at openjdk.org  Mon Jul  7 14:19:52 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 7 Jul 2025 14:19:52 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
Message-ID: <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>

On Mon, 7 Jul 2025 09:29:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process more reviewer comments

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 129:

> 127:         view.notifyMouse(MouseEvent.DOWN, getGlassEventButton(buttons), (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
> 128:         int buttonCode = getGlassEventButton(buttons);
> 129:         view.notifyMouse(MouseEvent.DOWN, buttonCode, (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);

This code (`view.notifyMouse(...`) is duplicated, and there are two notifications of mouse down while there should be just one.

The first line can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190246607

From jvos at openjdk.org  Mon Jul  7 14:46:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:19 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v8]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <kxr1DwwMl9H8bBHEL503ggl9d4gg-SRgVDAN68hs6Gw=.8400b0e7-978a-4d84-abaa-bd2e17fe3e3d@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Do not invoke notifyMouse twice

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/479a8149..3d64f2ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 14:46:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:19 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
 <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>
Message-ID: <ZHSaaTPZ3x75xy58oF3XVefBTcfw_Dj8JwMYx0t5E48=.65f72a3e-9540-4ad5-9eb5-5d85e8fa56e0@github.com>

On Mon, 7 Jul 2025 14:17:37 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process more reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 129:
> 
>> 127:         view.notifyMouse(MouseEvent.DOWN, getGlassEventButton(buttons), (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
>> 128:         int buttonCode = getGlassEventButton(buttons);
>> 129:         view.notifyMouse(MouseEvent.DOWN, buttonCode, (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
> 
> This code (`view.notifyMouse(...`) is duplicated, and there are two notifications of mouse down while there should be just one.
> 
> The first line can be removed.

Right, good catch!
I removed that first line.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190305053

From jvos at openjdk.org  Mon Jul  7 14:46:20 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:20 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <Q3wjEB3nQCMdt-NFnKS9lLi5_3eUbxQZDoQq0rsMylk=.fde50dcb-d51f-461f-984f-958cee26d052@github.com>

On Fri, 27 Jun 2025 20:24:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 40:
> 
>> 38:             latch.await();
>> 39:         } catch (InterruptedException e) {
>> 40:             e.printStackTrace();
> 
> should we print here or send to `Application.reportException(e)` ?

the method has been removed as it wasn't used.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190305902

From martinfox656 at gmail.com  Mon Jul  7 14:50:05 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 7 Jul 2025 07:50:05 -0700
Subject: Inconsistent drawing/layouts of Dialogs & show()/showAndWait()
 differences
In-Reply-To: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>
References: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>
Message-ID: <D51A5B9D-07DC-4B95-80EE-7E1B7FDD731C@gmail.com>

Cormac,

When you call Dialog.show everything happens in the order you expect. When you call Dialog.showAndWait the order of operations changes. For one, the Dialog code issues the DIALOG_SHOWN event *before* showing the window (it wants to send out that event before an internal call to Window.showAndWait blocks). For two, when Window.sizeToScene is called on a window that?s not yet visible it gets deferred. The end result is that with Dialog.showAndWait your onShown handler gets called before the window is sized to the scene but when you use Dialog.show your onShown handler is called after.

I don?t think any of this is documented. I've run into the deferred sizeToScene behavior before. I didn?t dig much but it looks like it was added over a decade ago in response to some bug reports. The timing of Dialog.setOnShown is also old behavior. There?s a comment in the Dialog.java about this:

>  // this is slightly odd - we fire the SHOWN event before the show()
>  // call, so that users get the event before the dialog blocks

So I can see what?s going on in case #2. Due to the re-ordering the sizeToScene logic is happening after the window?s minimum size is set. The docs don?t say what should happen if the scene?s desired size is less than the window?s minimum. What you?re getting is a scene that doesn?t fill the window. One work-around for case 2 is to call setOnShown on the dialog?s window instead of the dialog itself.

BTW, I think what you?re seeing in case #3 is correct and not a bug. You?re altering the size of the scene after the window has been sized and shown. I wouldn?t expect the window to automatically re-size to match the new scene dimensions. I think the expectation is that you would alter the scene?s dimensions in onShowing instead of onShown.

Martin

> On Jul 3, 2025, at 2:24?PM, Cormac Redmond <credmond at certak.com> wrote:
> 
> Hi,
> 
> I have noticed inconsistent and confusing size/layout behaviour with Dialogs when changing min width or height (after shown).
> 
> The behaviour depends on whether changing min width/height on the Stage, or the DialogPane itself, and whether show() or showAndWait() is used.
> 
> In summary:
> Set Stage mins + show()
> no bug
>  Set Stage mins + showAndWait()
> improper layout: background applies only to label (i.e., size before re-size), button wrong position, re-sizing window fixes the problem
> 3 Set DialogPane mins + show()
> min sizes are ignored, button is visible, until it comes into focus, and then the button disappears, you can find it if you resize window close to the mins set
> 4 Set DialogPane mins + showAndWait()
> no bug
> It's happening in JFX23/24/25. Note, these may seem trivial/fixable, or you may ask "why would you do that?", but there are reasons I won't clutter the mail with.
> 
> Anyway, it's best presented with a set of examples and code.
> 
> Re points 1 and 2 above, exact same code, except red is showAndWait() and green is show():
> 
> <image.png>
> 
> Obviously, they should behave the same. Then slightly resize the red one:
> 
> <image.png>
> 
> 
> Examples 3 and 4 above -- again, same code. Purple is show(), yellow is showAndWait().
> 
> <image.png>
> 
> After you close the yellow dialog:
> 
> <image.png>
> 
> They should be the same size from the outset.
> 
> 
> 
> public class DialogBug extends Dialog<Boolean> {
> 
>     public DialogBug(final String s, boolean flip) {
>         setTitle("Bug");
>         setResizable(true);
> 
>         final DialogPane dp = getDialogPane();
>         dp.setStyle(s);
>         dp.getButtonTypes().add(ButtonType.CLOSE);
>         dp.setContent(new Label("Content"));
> 
>         // Setting stage size causes the bug
>         setOnShown(e -> {
> 
>             if (flip) {
>                 // Set stage sizes
>                 Stage st = (Stage) dp.getScene().getWindow();
>                 st.setMinHeight(260);
>                 st.setMinWidth(360);
>             } else {
>                 // Set dialog sizes: note buttons disappear when you resize
>                 dp.setMinHeight(260);
>                 dp.setMinWidth(360);
>             }
>         });
>     }
> 
>     public static class BugApp extends Application {
>         @Override
>         public void start(final Stage st) throws Exception {
> 
>             final boolean FLIP_ME = true; // make true for other bug
> 
>             if (FLIP_ME) {
>                 // Note: bug doesn't happen when using show() only. Stage is fully green on show.
>                 new DialogBug("-fx-background-color: green;", true).show(); // NO BUG
> 
>                 // showAndWait presents the bug; background not fully drawn, button shifts on re-size
>                 new DialogBug("-fx-background-color: red;", true).showAndWait(); // BUG
>             } else {
>                 // A different type of issue: two different sizes and button behaviour
>                 // Notice:
>                 // - same dialogs, different sizes
>                 // - how button in purple dialog shifts when yellow dialog pane is closed
>                 new DialogBug("-fx-background-color: purple;", false).show(); // BUG
>                 
>                 new DialogBug("-fx-background-color: yellow;", false).showAndWait(); // NO BUG
>             }
>         }
>     }
> }
> 
> Thoughts?
> 
> 
> 
> Kind Regards,
> Cormac

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250707/6583727b/attachment.htm>

From angorya at openjdk.org  Mon Jul  7 15:06:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 15:06:50 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <dPBLv09XBCvhCatQ3aGccbZXv_dpfrPE1xdh6vGA00k=.0ea816cd-9a3e-4416-bb67-063306baa26c@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

It might be better to create a new JBS ticket if this is a new bug (or reference an existing one).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3045549633

From angorya at openjdk.org  Mon Jul  7 15:30:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 15:30:47 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <MS8WacJV6w0NlBecoeWXmDsrAxQKLkjK53RYPhAmcMQ=.e05e1ddc-1699-4e99-9a80-db272aeac687@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

Should the new library be copied to `rt/build/sdk/lib` as part of the build?

I've added the directory you mentioned to the `java.library.path` and it still fails to open the library:


-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl/msl"


Passing `rt/modules/javafx.graphics/build/msl` directory also fails:


-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/build/msl"

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3045624861

From zelmidaoui at openjdk.org  Mon Jul  7 16:26:46 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 7 Jul 2025 16:26:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I tried it, the tests pass successfully however when trying in MonkeyTester I am not able to show characters and caret path when I check the box it throws an error :
`Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.oracle.tools.fx.monkey.util.TextShapeLogic.ordinal()" because "logic" is null`

(https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3045808969

From angorya at openjdk.org  Mon Jul  7 16:34:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 16:34:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>
Message-ID: <PHdgcKUWOCclMZLb3KnVw_reH8P1bTzCWMSDvdqX2QU=.7b69013e-08fa-472e-a96c-e9325d737d10@github.com>

On Mon, 7 Jul 2025 16:23:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> when trying in MonkeyTester

Please update (git pull) the monkey tester and retry (or just select a value in the "API:" combo box.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3045849075

From mfox at openjdk.org  Mon Jul  7 16:59:13 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 16:59:13 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
References: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
Message-ID: <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@github.com>

> The Mac platform code figures out where characters are on the keyboard as the user types. The character table is updated on every key press by calling a registerKeyEvent: in GlassApplication. This character table is used to resolve KeyCharacterCombination accelerators like Cmd + "+".
> 
> On a US English layout when the user types Cmd + "+" on the main keyboard they're actually typing Cmd + "=". There's special handling in macOS for this combination that can cause two NSEvents to be sent and so there's special handling in the Glass code so we don't process both events. When this special case is invoked registerKeyEvent: isn't being called to update the character table. This bug was introduced when code was consolidated in PR #1528.
> 
> The fix is a simple one-liner. I've added a test for this in the KeyboardTest.java program. It's an isolated test because it requires the Robot to send events to hold down a modifier while a character key is pressed. I also updated some obsolete comments and tweaked it to test all KeyCharacterCombinations since they should now work reliably on all platforms.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Reverted manual tests, added system test, changed check for fake performKeyEquivalent event.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1837/files
  - new: https://git.openjdk.org/jfx/pull/1837/files/9ba898a9..524b3f43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1837&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1837&range=00-01

  Stats: 436 lines in 3 files changed: 295 ins; 128 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1837.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1837/head:pull/1837

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

From mfox at openjdk.org  Mon Jul  7 16:59:13 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 16:59:13 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably
In-Reply-To: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
References: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
Message-ID: <1r5DEJWI74SZP4EohdKIwWNugj6sGmL4cKl-WFe4JAs=.a789ba5a-663e-4022-a5e3-f1446ffeb9a7@github.com>

On Mon, 30 Jun 2025 16:58:00 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The Mac platform code figures out where characters are on the keyboard as the user types. The character table is updated on every key press by calling a registerKeyEvent: in GlassApplication. This character table is used to resolve KeyCharacterCombination accelerators like Cmd + "+".
> 
> On a US English layout when the user types Cmd + "+" on the main keyboard they're actually typing Cmd + "=". There's special handling in macOS for this combination that can cause two NSEvents to be sent and so there's special handling in the Glass code so we don't process both events. When this special case is invoked registerKeyEvent: isn't being called to update the character table. This bug was introduced when code was consolidated in PR #1528.
> 
> The fix is a simple one-liner. I've added a test for this in the KeyboardTest.java program. It's an isolated test because it requires the Robot to send events to hold down a modifier while a character key is pressed. I also updated some obsolete comments and tweaked it to test all KeyCharacterCombinations since they should now work reliably on all platforms.

Well, now I?ve gone and re-written this PR.

As stated earlier sometimes a single key press can lead to multiple calls to performKeyEquivalent. During testing I discovered that the way Glass checks for this doesn?t always work. Currently it tries to guess which key event might lead to a second one but there are cases where it guesses wrong (e.g. the Hebrew layout). I?ve decided to take a different approach, detecting and discarding the second event. The logic is:

- Is the new key event not the current event (theEvent != NSApp.currentEvent)?
- Are we still working on an earlier event (NSApp.currentEvent == lastKeyEvent)?

If both these conditions are true we can ignore the new key event.

I?ve reverted the changes to the manual test and added a system test. It covers a smattering of carefully selected keys including the combinations involved in this bug. Currently it?s restricted to macOS and Latin keyboards because the Hebrew keyboard on macOS is crazy. I will expand this to other platforms when I have time to do the testing. I?ve run this test on macOS using US English, French, German, Spanish, Hebrew, Devanagari, and a few other layouts.

(About that Hebrew layout. When you hold down Command all the keys start behaving like a US English layout, including the punctuation keys. So the key you press to type a period is entirely different from the key that generates Cmd+period.)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1837#issuecomment-3045927258

From jpereda at openjdk.org  Mon Jul  7 17:17:46 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 7 Jul 2025 17:17:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
Message-ID: <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>

On Mon, 7 Jul 2025 09:29:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process more reviewer comments

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 296:

> 294:         int b = rgba & 0xFF;
> 295: 
> 296:         Color color = Color.rgb(r, g, b, a);

`Color::rgb` requires opacity between 0 and 1, therefore, you need:


Color color = Color.rgb(r, g, b, a / 255.0);

Minor: you can inline the variable.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190667156

From jvos at openjdk.org  Mon Jul  7 17:56:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 17:56:06 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Specify A as a double.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/3d64f2ce..2925f42c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 17:56:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 17:56:06 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
 <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>
Message-ID: <9e-9LkDqiQl_GKfVnoEwDGLzL52OSzgrMfrA2UqypK4=.29879acf-c39b-41a1-9609-0bcb9468bc6b@github.com>

On Mon, 7 Jul 2025 17:15:12 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process more reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 296:
> 
>> 294:         int b = rgba & 0xFF;
>> 295: 
>> 296:         Color color = Color.rgb(r, g, b, a);
> 
> `Color::rgb` requires opacity between 0 and 1, therefore, you need:
> 
> 
> Color color = Color.rgb(r, g, b, a / 255.0);
> 
> Minor: you can inline the variable.

Good catch, thanks!
Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190726879

From azvegint at openjdk.org  Mon Jul  7 18:47:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 7 Jul 2025 18:47:45 GMT
Subject: Integrated: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered
 to wrong place
In-Reply-To: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
References: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
Message-ID: <2bvZ8SFMbFUMSMORDVj8-BVlSAmrPS7HxIEQSaDu-ag=.547c2656-98fc-43de-afca-f207e6220211@github.com>

On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot.
> More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753)
> 
> In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time.
> 
> This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps).
> 
> ----
> 
> * The remote desktop for Robot is enabled by default on GnomeShell 47+
> * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46)
> * The key handling might still have bugs.
> * The main goal is to add this new functionality.  If there are small issues that can't be solved right away,  I will prefer to fix them in follow up fixes.

This pull request has now been integrated.

Changeset: 639a5950
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/639a5950b6eae7870fd9d9e84f9ce81322aaab82
Stats:     1312 lines in 12 files changed: 1081 ins; 139 del; 92 mod

8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place

Reviewed-by: lkostyra, arapte

-------------

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

From kevin.rushforth at oracle.com  Mon Jul  7 18:57:34 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jul 2025 11:57:34 -0700
Subject: Proposed schedule for JavaFX 25
In-Reply-To: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>
References: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>
Message-ID: <2de91cd1-655a-4f62-b525-4a5fd65dec0b@oracle.com>

As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 25 starts on Thursday, 
July 17, 2025 at 16:00 UTC (09:00 US/Pacific time), ten days from now.

During rampdown of JavaFX 25, the "master" branch of the jfx repo will 
be open for JavaFX 26 fixes.

Please allow sufficient time for any feature that needs a CSR. New 
features should be far enough along in the review process that you can 
finalize the CSR no later than Thursday, July 10, or it is likely to 
miss the window for this release, in which case it can be targeted for 
JavaFX 26.

We will follow the same process as in previous releases for getting 
fixes into JavaFX 25 during rampdown. I'll send a message with detailed 
information when we fork, but candidates for fixing during RDP1 are 
P1-P3 bugs (as long as they are not risky) and test or doc bugs of any 
priority. Some small enhancements might be considered during RDP1, but 
they require explicit approval; the bar will be high for such requests.

-- Kevin

On 5/10/2025 9:16 AM, Kevin Rushforth wrote:

> Here is the proposed schedule for JavaFX 25:
>
> RDP1: Jul 17, 2025 (aka ?feature freeze?)
> RDP2: Aug 7, 2025
> RC: Aug 28, 2025 (aka ?code freeze?)
> GA: Sep 16, 2025
>
> We plan to fork a jfx25 stabilization branch at RDP1.
>
> The start of RDP1, the start of RDP2, and the code freeze will be 
> 16:00 UTC on the respective dates.
>
> Please let Johan or me know if you have any questions.
>
> -- Kevin


From mstrauss at openjdk.org  Mon Jul  7 20:52:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 20:52:45 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I'm a bit skeptical with this approach. You describe the existing methods as "buggy". If that's the case, being good stewards of the API should point us towards fixing the bugs instead of adding new methods that seem confusingly similar.

The JBS ticket includes the following information:

> This bug might present a compatibility risk for existing applications which tried to compensate for it by getting the borders and padding from the corresponding Nodes and adding it to each path element (or setting translateX/Y).

Is this just a guess, or do you have any data to corroborate the problem? Messing up the API and baking "buggy" implementations into JavaFX forever should require quite a bit of justification.

Have alternatives been discussed? For example, we could have a system property to fall back to the old behavior.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046484454

From angorya at openjdk.org  Mon Jul  7 20:59:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 20:59:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
Message-ID: <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>

On Mon, 7 Jul 2025 20:49:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Have alternatives been discussed?

Yes, internally.  This PR has been out for quite a while, too.

The priority here is not to break the existing applications that might have coded a workaround.  We offer a new set of (better named) APIs withe the right behavior, while deprecating (not for removal) the existing ones.

Adding a system property seems a worse choice since it will break the apps and force the change.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046500268

From mstrauss at openjdk.org  Mon Jul  7 21:13:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 21:13:43 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
 <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>
Message-ID: <BAvSCu0oxktifrjbfWiWv-YEOs-ST1wxISMWF08fHac=.f8b76475-d0f8-4b7e-8760-c5df7adbf46f@github.com>

On Mon, 7 Jul 2025 20:56:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Have alternatives been discussed?
> 
> Yes, internally. This PR has been out for quite a while, too.

Okay... the OpenJFX project states in CONTRIBUTING.md, section "New features / API additions":
_Discuss the proposed feature on the [openjfx-dev](https://mail.openjdk.org/mailman/listinfo/openjfx-dev) mailing list._

I'm not sure how "internal" discussions qualify. Oracle is not the only stakeholder in this project.

> The priority here is not to break the existing applications that might have coded a workaround.

My question was whether this is an educated guess, or whether this problem is corroborated by data.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046533056

From andy.goryachev at oracle.com  Mon Jul  7 21:23:30 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 7 Jul 2025 21:23:30 +0000
Subject: Enhanced Text/TextFlow APIs
Message-ID: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Summary

This change adds new methods to the TextFlow which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.

Problem

A number of methods in TextFlow fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
?         caretShape
?         hitTest
?         rangeShape

Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the TextFlow and the Text classes.

Solution

The solution is two-fold:
1.     deprecate the buggy methods (not for removal), adding explanations in their javadoc comments
2.     add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.

The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670

Testing

Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):

https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Issues
?         JDK-8341438<https://bugs.openjdk.org/browse/JDK-8341438>: TextFlow: incorrect caretShape(), hitTest(), rangeShape() with non-empty padding/border (Bug - P4)
?         JDK-8357594<https://bugs.openjdk.org/browse/JDK-8357594>: Text/TextFlow: strike through shape (Enhancement - P4)
?         JDK-8358000<https://bugs.openjdk.org/browse/JDK-8358000>: Enhanced Text/TextFlow APIs (CSR)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250707/5d115b67/attachment-0001.htm>

From angorya at openjdk.org  Mon Jul  7 21:27:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 21:27:44 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <TXLJanaTrCFRDuOBYk1EqinImHJbheqvduWrCs2HkdE=.e42cdeb7-22be-4e19-b24f-7fe314520d8e@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

Point taken.  Posted to the mailing list.

> My question was whether this is an educated guess

It's an educated guess.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046564373

From duke at openjdk.org  Mon Jul  7 23:47:46 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Mon, 7 Jul 2025 23:47:46 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <z7mqZMo_ZfO4qVvJlAzoz7knjEadpJrCrZXN8x4uUNI=.c09e28e8-6d89-4931-96c1-5c006302988f@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

FYI to any reviewer: I've been using this branch's EXTENDED/HeaderBar extensively now without any new issues...

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3046847252

From almatvee at openjdk.org  Tue Jul  8 01:05:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 01:05:43 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
 <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
Message-ID: <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>

On Fri, 4 Jul 2025 13:03:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:
>> 
>>> 804: 
>>> 805:         NSMutableData* readData = nil;
>>> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();
>> 
>> `URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?
>
> In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
> The cacheEntry is created by the `NativeMediaAudioClip<init>` which is indirectly called by the AudioClip constructor.
> 
> In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.
> 
> Alternatively, we might try to use the already-created ConnectionHolder instead of creating a new one in OSXMediaPlayer.mm.

Yes, you right `MemoryConnectionHolder` in case of jar, but only for AudioClip. MediaPlayer does not use it. I tested AudioClip with jar with and without random access. Without random access I only hear some clicking sounds, so looks like it does not work completely. With random access I can only hear audio for like 30 seconds and then it loops, so looks like it is broken as well.

Can you play audio file correctly via AudioClip?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2191270417

From michaelstrau2 at gmail.com  Tue Jul  8 02:40:48 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 8 Jul 2025 04:40:48 +0200
Subject: Enhanced Text/TextFlow APIs
In-Reply-To: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>

In most cases, I would advise against having similarly-named methods
that exhibit different semantics. If the behavior of the existing
methods is indeed a bug (and not just different, but legitimate
semantics), then fixing that would be best. We've done breaking
changes in the past where appropriate, and expect applications to make
necessary changes in their API use when switching to a new version of
JavaFX. Always keeping old behavior around runs the risk of
fossilizing the API in the long run.

In rare cases, and especially when necessary changes would be more
involved, there's the option to hide the previous behavior behind a
system property. Setting a system property in lieu of changing code is
a low-effort option for applications that are not prepared to fix
their code just yet.

If we want to keep the old methods around indefinitely, another option
would be to make the new methods clearly different to indicate their
changed semantics.

For example, for the existing method `rangeShape(int, int)`, we could
add another method `rangeShapeWithLineSpacing(int, int)`. This makes
the semantics of the method abundantly clear to users, and keeps the
old method around. It also avoids the proposed boolean argument
`includeLineSpacing`, which is usually better API design.

As another example, the existing method `caretShape(int, boolean)`
could be paired with `caretShapeWithInsets(int, boolean)`.

My main criticism is that method pairings like `rangeShape` and
`getRangeShape` muddy the API waters. We'd never have done that, had
we thought about the correct semantics earlier. Evolving an API is
always hard, but the goal should be to have the new API fit well with
the existing API, as if it had been thought of from the beginning.

From almatvee at openjdk.org  Tue Jul  8 02:53:45 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 02:53:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
 <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
 <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>
Message-ID: <aiqgrMkwcD-w_0JWZ6-CU-Wiiv6nFUJu2-O7UQ_ts0s=.5f8b1b73-2475-4205-9400-4593c0783ce9@github.com>

On Tue, 8 Jul 2025 01:03:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
>> The cacheEntry is created by the `NativeMediaAudioClip<init>` which is indirectly called by the AudioClip constructor.
>> 
>> In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.
>> 
>> Alternatively, we might try to use the already-created ConnectionHolder instead of creating a new one in OSXMediaPlayer.mm.
>
> Yes, you right `MemoryConnectionHolder` in case of jar, but only for AudioClip. MediaPlayer does not use it. I tested AudioClip with jar with and without random access. Without random access I only hear some clicking sounds, so looks like it does not work completely. With random access I can only hear audio for like 30 seconds and then it loops, so looks like it is broken as well.
> 
> Can you play audio file correctly via AudioClip?

I figure it out. Seek is ignored for random access, so setting `pos = 0` will always read from begging of the file. We should read from `dataRequest.requestedOffset`. I am attaching proposed patch which I tested and works fine.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2191370087

From almatvee at openjdk.org  Tue Jul  8 02:58:44 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 02:58:44 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

[8357714.0.patch](https://github.com/user-attachments/files/21113478/8357714.0.patch)
- Patch which does not do seek with random access and it will read data starting from `dataRequest.requestedOffset`.
- For size `requestedLength` is used. I do not see a need to use anything else. It will be limited to requested length or 1 Megabyte.
- Added `NULL` checks and `callbacks` release.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3047188025

From michaelstrau2 at gmail.com  Tue Jul  8 04:22:24 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 8 Jul 2025 06:22:24 +0200
Subject: Debugger
In-Reply-To: <007f01dbee96$e1011050$a30330f0$@weichi.com>
References: <007f01dbee96$e1011050$a30330f0$@weichi.com>
Message-ID: <CAJEpuXTceik+zdEqXO2=Lp+zUSFtz+SexiXRATSLjgr8Nu+qdw@mail.gmail.com>

Probably because no one felt the need to work on a public API for it yet.
There seems to be some prior work for WebView debugging, maybe this
can be of some use: https://github.com/vsch/Javafx-WebView-Debugger


On Sun, Jul 6, 2025 at 6:56?PM <maw at weichi.com> wrote:
>
> Why is WebEngine Debugger private?
>
> Marvin Wolfthal
> maw at weichi.com
> http://www.marvinwolfthal.com
> https://www.youtube.com/@marvinwolfthal6402
>

From jvos at openjdk.org  Tue Jul  8 07:26:28 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 8 Jul 2025 07:26:28 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v2]
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process reviewer comments
  Add null checks
  Fix errors in position and length calculations

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1839/files
  - new: https://git.openjdk.org/jfx/pull/1839/files/b1459d09..e99a8504

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1839&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1839&range=00-01

  Stats: 19 lines in 2 files changed: 8 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1839.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1839/head:pull/1839

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

From jvos at openjdk.org  Tue Jul  8 07:26:28 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 8 Jul 2025 07:26:28 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>
Message-ID: <AIPROV-1aZ09SPr9otDP7rnzX_5vuvrwHigDd7sKis0=.dd73d09c-749d-4671-82e7-167f19fcc6d4@github.com>

On Tue, 8 Jul 2025 02:55:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> [8357714.0.patch](https://github.com/user-attachments/files/21113478/8357714.0.patch)
> - Patch which does not do seek with random access and it will read data starting from `dataRequest.requestedOffset`.
> - For size `requestedLength` is used. I do not see a need to use anything else. It will be limited to requested length or 1 Megabyte.
> - Added `NULL` checks and `callbacks` release.

@sashamatveev Thanks a lot. That all makes sense, and it seems to work indeed with the corrected position/length calculations.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3047688717

From lkostyra at openjdk.org  Tue Jul  8 12:06:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 8 Jul 2025 12:06:53 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

Good work!

Reviewed the Metal-native-side of this commit (`native-prism-mtl` folder) and left some comments to talk through, nothing extremely major though. I'll verify the code on my side once we get closer to review completion.

modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1437:

> 1435:     [pCtx endCurrentRenderEncoder];
> 1436: 
> 1437:     id<MTLCommandBuffer> commandBuffer = [pCtx getCurrentCommandBuffer];

I think most of this function should become a `MetalContext` method that would be called here. That way we separate the Metal-related implementation from JNI entry points and it follows the pattern of other JNI entry points in this file.

modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m line 167:

> 165:         pipeState = [[context getPipelineManager] getPipeStateWithFragFunc:fragmentFunction
> 166:                                                              compositeMode:compositeMode];
> 167:         [psDict setObject:pipeState forKey:keyCompMode];

I am not 100% sure why there is a need to duplicate PipelineState dictionaries here and to create a Shader-specific cache of States. If you need to get a PipelineState, why not always directly call on `MetalPipelineManager`?

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 235:

> 233:     id<MTLCommandBuffer> commandBuffer = [context getCurrentCommandBuffer];
> 234:     @autoreleasepool {
> 235:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

Similarly to `MetalContext` comment, I think we should separate JNI entry point code and argument parsing/converting from actual Metal-reaching implementation. I would also move this to a `MetalTexture` method.

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 300:

> 298: 
> 299:     @autoreleasepool {
> 300:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

As above

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 364:

> 362: 
> 363:     @autoreleasepool {
> 364:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

As above

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 407:

> 405: 
> 406:     @autoreleasepool {
> 407:         id<MTLDevice> device = [context getDevice];

As above

-------------

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-2961851748
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192155071
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192281270
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192317134
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192305858
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192306212
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192307217

From lkostyra at openjdk.org  Tue Jul  8 12:06:55 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 8 Jul 2025 12:06:55 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v4]
In-Reply-To: <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
Message-ID: <vV30OHb08gx26owOe_1_czcHd680PfVmlC3k-P3ycmQ=.51d079c1-8175-4ef9-8d6e-4d3c00622bbd@github.com>

On Wed, 25 Jun 2025 11:28:57 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use appropriate layer for setting opacity

modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.h line 78:

> 76:     id<MTLRenderCommandEncoder> phongEncoder;
> 77:     id<MTLRenderCommandEncoder> lastPhongEncoder;
> 78:     MetalShader* currentShader;

Might be my obj-C lack-of-knowledge - why some objects here use pointers, while others use `id<>`?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2168906886

From andy.goryachev at oracle.com  Tue Jul  8 15:16:56 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 8 Jul 2025 15:16:56 +0000
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In-Reply-To: <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
Message-ID: <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>

I generally agree.  In this particular case, the distinction is clear and explained in the docs (perhaps it could be explained better, your suggestions are always welcomed).

The new names, I think, fit better: getCaretShape() are far better than getCaretShapeWithInsets (what insets?  why?  what makes insets so special?).

The proposed solution provides the new API without breaking the existing apps.  The apps can take their time to migrate to the new API in due course.  I believe we've done this in the past where things got deprecated but not for removal.

So I think this is a good compromise - things get fixed without immediately breaking the existing apps, a win-win.

Cheers,
-andy





From: Michael Strau? <michaelstrau2 at gmail.com>
Date: Monday, July 7, 2025 at 19:41
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In most cases, I would advise against having similarly-named methods
that exhibit different semantics. If the behavior of the existing
methods is indeed a bug (and not just different, but legitimate
semantics), then fixing that would be best. We've done breaking
changes in the past where appropriate, and expect applications to make
necessary changes in their API use when switching to a new version of
JavaFX. Always keeping old behavior around runs the risk of
fossilizing the API in the long run.

In rare cases, and especially when necessary changes would be more
involved, there's the option to hide the previous behavior behind a
system property. Setting a system property in lieu of changing code is
a low-effort option for applications that are not prepared to fix
their code just yet.

If we want to keep the old methods around indefinitely, another option
would be to make the new methods clearly different to indicate their
changed semantics.

For example, for the existing method `rangeShape(int, int)`, we could
add another method `rangeShapeWithLineSpacing(int, int)`. This makes
the semantics of the method abundantly clear to users, and keeps the
old method around. It also avoids the proposed boolean argument
`includeLineSpacing`, which is usually better API design.

As another example, the existing method `caretShape(int, boolean)`
could be paired with `caretShapeWithInsets(int, boolean)`.

My main criticism is that method pairings like `rangeShape` and
`getRangeShape` muddy the API waters. We'd never have done that, had
we thought about the correct semantics earlier. Evolving an API is
always hard, but the goal should be to have the new API fit well with
the existing API, as if it had been thought of from the beginning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250708/0feff1af/attachment-0001.htm>

From kevin.rushforth at oracle.com  Tue Jul  8 16:50:33 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 8 Jul 2025 09:50:33 -0700
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In-Reply-To: <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
 <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <2ba0c52a-8703-4fed-9272-e5a9c5412214@oracle.com>

I agree with Andy on this, provided that we explain it well. The 
proposed names are what I would have chosen in the first place, and by 
leaving the existing methods in place -- deprecated, but not for removal 
-- we avoid the very real possibility of introducing a regression. It 
isn't an ideal choice, but I think it's the best on in this case.

-- Kevin

On 7/8/2025 8:16 AM, Andy Goryachev wrote:
>
> I generally agree.? In this particular case, the distinction is clear 
> and explained in the docs (perhaps it could be explained better, your 
> suggestions are always welcomed).
>
> The new names, I think, fit better: getCaretShape() are far better 
> than getCaretShapeWithInsets (what insets?? why? what makes insets so 
> special?).
>
> The proposed solution provides the new API without breaking the 
> existing apps.? The apps can take their time to migrate to the new API 
> in due course.? I believe we've done this in the past where things got 
> deprecated but not for removal.
>
> So I think this is a good compromise - things get fixed without 
> immediately breaking the existing apps, a win-win.
>
> Cheers,
>
> -andy
>
> *From: *Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Monday, July 7, 2025 at 19:41
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Cc: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: Enhanced Text/TextFlow APIs
>
> In most cases, I would advise against having similarly-named methods
> that exhibit different semantics. If the behavior of the existing
> methods is indeed a bug (and not just different, but legitimate
> semantics), then fixing that would be best. We've done breaking
> changes in the past where appropriate, and expect applications to make
> necessary changes in their API use when switching to a new version of
> JavaFX. Always keeping old behavior around runs the risk of
> fossilizing the API in the long run.
>
> In rare cases, and especially when necessary changes would be more
> involved, there's the option to hide the previous behavior behind a
> system property. Setting a system property in lieu of changing code is
> a low-effort option for applications that are not prepared to fix
> their code just yet.
>
> If we want to keep the old methods around indefinitely, another option
> would be to make the new methods clearly different to indicate their
> changed semantics.
>
> For example, for the existing method `rangeShape(int, int)`, we could
> add another method `rangeShapeWithLineSpacing(int, int)`. This makes
> the semantics of the method abundantly clear to users, and keeps the
> old method around. It also avoids the proposed boolean argument
> `includeLineSpacing`, which is usually better API design.
>
> As another example, the existing method `caretShape(int, boolean)`
> could be paired with `caretShapeWithInsets(int, boolean)`.
>
> My main criticism is that method pairings like `rangeShape` and
> `getRangeShape` muddy the API waters. We'd never have done that, had
> we thought about the correct semantics earlier. Evolving an API is
> always hard, but the goal should be to have the new API fit well with
> the existing API, as if it had been thought of from the beginning.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250708/5988b371/attachment.htm>

From vdyakov at openjdk.org  Tue Jul  8 18:05:44 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 8 Jul 2025 18:05:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <snIlRRTOvjEd6LTdgLxDlmIfRp8TZDpCvWGfTTpz2JQ=.6c1e342b-368a-4a2d-b47b-5cc16064e94b@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

@andy-goryachev-oracle @arapte please review

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1840#issuecomment-3049844834

From angorya at openjdk.org  Tue Jul  8 18:15:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 18:15:49 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <bgDUVn04XduDIy9ySSB0Scw7qhSq0wSF-4T28OuWZ-4=.797b41f5-9db9-4622-93cf-6a6ab084b342@github.com>

On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @Override

Did a bit more digging in Eclipse:

1. the resource is in `javafx.graphics.jar` under correct path `com/sun/prism/mtl/msl/jfxshaders.metallib`
2. the class loader fails to locate it in BuildinClassLoader:findResourceAsStream() L293
because it tries to load the stream from the file system, not a jar.

Even after I add the dir with the resource to the `java.library.path`

-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl"


The reason is that eclipse is looking for the resources for the graphics module in
`rt/modules/javafx.graphics/bin` where the module classes are compiled to, and not in other places.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3049869591

From kcr at openjdk.org  Tue Jul  8 19:04:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 19:04:49 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
Message-ID: <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>

On Fri, 20 Jun 2025 01:39:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - Merge branch 'master' into feature/media-queries
>  - Merge branch 'master' into feature/media-queries
>  - use custom mediaFeature javadoc tag
>  - Merge branch 'master' into feature/media-queries
>  - fix wrong <br> HTML tags
>  - Merge branch 'master' into feature/media-queries
>  - doc
>  - reorder Scene.Preferences.colorScheme
>  - move doc from Scene.Preferences to Platform.Preferences
>  - ... and 40 more: https://git.openjdk.org/jfx/compare/fc4642db...b01f0414

The API changes look good. The cssref docs and the class docs for the new Scene.Preferences class look good. The one problem I see is that the `@mediaFeature` javadoc tag doesn't render anything, at least not when I run `gradle javadoc` using the default JDK 24.

You might need to revert this change and link to the cssref manually.

I note that the CSR spec was done before this change, so depending on how you resolve this, the spec should be regenerated.

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:

> 615:          *
> 616:          * @return the {@code persistentScrollBars} property
> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>

I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2998731760
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193197562

From kcr at openjdk.org  Tue Jul  8 20:29:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 20:29:59 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
Message-ID: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can 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 continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
> 
> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.

Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
 - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
 - set gradle version min to 8.10.2
 - 8359387: Bump minimum JDK version for JavaFX to JDK 23

-------------

Changes: https://git.openjdk.org/jfx/pull/1827/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1827&range=01
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1827.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1827/head:pull/1827

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

From mstrauss at openjdk.org  Tue Jul  8 20:32:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 20:32:51 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
Message-ID: <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>

On Tue, 8 Jul 2025 18:32:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - Merge branch 'master' into feature/media-queries
>>  - Merge branch 'master' into feature/media-queries
>>  - use custom mediaFeature javadoc tag
>>  - Merge branch 'master' into feature/media-queries
>>  - fix wrong <br> HTML tags
>>  - Merge branch 'master' into feature/media-queries
>>  - doc
>>  - reorder Scene.Preferences.colorScheme
>>  - move doc from Scene.Preferences to Platform.Preferences
>>  - ... and 40 more: https://git.openjdk.org/jfx/compare/fc4642db...b01f0414
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:
> 
>> 615:          *
>> 616:          * @return the {@code persistentScrollBars} property
>> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>
> 
> I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).

That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.

So it seems like we have several options:
1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
3. Don't use a custom javadoc tag at all.

I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193389437

From mstrauss at openjdk.org  Tue Jul  8 20:39:48 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 20:39:48 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
Message-ID: <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>

On Tue, 8 Jul 2025 20:30:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:
>> 
>>> 615:          *
>>> 616:          * @return the {@code persistentScrollBars} property
>>> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>
>> 
>> I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).
>
> That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.
> 
> So it seems like we have several options:
> 1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
> 2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
> 3. Don't use a custom javadoc tag at all.
> 
> I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.

I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193400531

From kcr at openjdk.org  Tue Jul  8 20:40:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 20:40:44 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23
In-Reply-To: <3u6WMk3UjdyP3ccVO-ZFk_JPI-Mg4O-dT4LeSpuQvUk=.0034a9e5-8827-4562-9f07-9eb335129f97@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <3u6WMk3UjdyP3ccVO-ZFk_JPI-Mg4O-dT4LeSpuQvUk=.0034a9e5-8827-4562-9f07-9eb335129f97@github.com>
Message-ID: <J06eGVpGOE1MQpSXy9VYypGnB3SNLjnNrFfcPl-4nxk=.cd1e0384-5db5-4d5c-a95c-b52e432b2a8b@github.com>

On Wed, 18 Jun 2025 17:26:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I will also need to merge master some time after #1832 is integrated, since there will be a (trivial) merge conflict for me to resolve.

This is now merged. The trivial conflict was in the surrounding context, not the diffs themselves.

@tiainen @arapte Can you re-review?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1827#issuecomment-3050239003

From almatvee at openjdk.org  Tue Jul  8 20:58:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 20:58:43 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v2]
In-Reply-To: <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>
Message-ID: <HONVxy6EdI1qlqte7zvVjtskITPnXTIfGNsRVWswWAc=.7a0eea44-8efc-4c74-ae92-d33b6f4492fc@github.com>

On Tue, 8 Jul 2025 07:26:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process reviewer comments
>   Add null checks
>   Fix errors in position and length calculations

modules/javafx.media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm line 331:

> 329:         CJavaInputStreamCallbacks *callbacks = new (nothrow) CJavaInputStreamCallbacks();
> 330:         jobject jConnectionHolder = CLocator::CreateConnectionHolder(env, jLocator);
> 331:         if (callbacks == NULL  || jConnectionHolder == NULL) {

Extra space after `callbacks == NULL`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2193427264

From kcr at openjdk.org  Tue Jul  8 21:11:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 21:11:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
Message-ID: <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>

On Tue, 8 Jul 2025 20:37:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.
>> 
>> So it seems like we have several options:
>> 1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
>> 2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
>> 3. Don't use a custom javadoc tag at all.
>> 
>> I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.
>
> I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.

Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.

I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193441226

From kcr at openjdk.org  Tue Jul  8 21:11:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 21:11:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
 <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
Message-ID: <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>

On Tue, 8 Jul 2025 21:05:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.
>
> Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.
> 
> I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.

Whichever option you decide, update the CSR to match. Then I'll Review the CSR and you can finalize it.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193446590

From mstrauss at openjdk.org  Tue Jul  8 21:27:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:27:06 GMT
Subject: RFR: 8345348: CSS media feature queries [v35]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <0Lu1396k5Dan8mVuMmowdrsnmJJws7NwNwjSRHWduz4=.07bedb53-f9ca-481c-9132-3113b596faf5@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

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

  documentation changes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/b01f0414..9405d47a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=34
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=33-34

  Stats: 40 lines in 2 files changed: 30 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

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

From angorya at openjdk.org  Tue Jul  8 21:31:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 21:31:54 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:

> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];

this change seems unrelated - is it a part of some other work?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193474924

From angorya at openjdk.org  Tue Jul  8 21:40:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 21:40:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

Like this very much, a good cleanup.

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 99:

> 97: }
> 98: 
> 99: - (jobject)getJAccessible {

should this K&R brace be reverted to the _objectively better_ style used elsewhere in this file?

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 113:

> 111:     GET_MAIN_JENV;
> 112:     if (env == NULL) return NULL;
> 113:     jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible],

not an expert, but do we really need to initialize `jresult` to NULL in line 110?
can the variable be declared in line 113 ?

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:

> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
> 190:     id s = [self requestNodeAttribute:@"AXSize"];
> 191:     if (p == NULL || s == NULL) {

not a big issue, but would it be (marginally) better to bail out early if p == NULL ?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1840#pullrequestreview-2999152480
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193476993
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193479120
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193484839

From mstrauss at openjdk.org  Tue Jul  8 21:44:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:44:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

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

  documentation changes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/9405d47a..0feee0dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=35
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=34-35

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1655.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655

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

From mstrauss at openjdk.org  Tue Jul  8 21:44:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:44:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
 <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
 <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>
Message-ID: <-E8Wn5Rgmy1xJzzxsdSuwOEIJr08d6EpltqTWlEhWXM=.382f2ab9-60bd-450f-aa87-14ee5b47b947@github.com>

On Tue, 8 Jul 2025 21:08:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.
>> 
>> I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.
>
> Whichever option you decide, update the CSR to match. Then I'll Review the CSR and you can finalize it.

I've updated the CSR to match.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193489323

From angorya at openjdk.org  Tue Jul  8 22:00:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 22:00:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <ZPxk2BzO6aSkRjKdhLzzcWm_C-YLmnu0cZaTjfTgriE=.c29db434-699d-4836-88b6-2523deb1d112@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

I don't see any obvious issues in the monkey tester with the Logging -> Accessibility enabled.

Here, for example, what it logs for the focusable label:


{time:1752011850468, log:"accessibility", "TEXT":""[?????????\n????????\n?????]""}
{time:1752011850468, log:"accessibility", "ROLE":""TEXT""}
{time:1752011850468, log:"accessibility", "LABELED_BY":"null"}

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1840#issuecomment-3050405287

From angorya at openjdk.org  Tue Jul  8 22:16:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 22:16:48 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
Message-ID: <zUMr9hYfrUk9y-8eQyqszlDdg11IcSuCWe_XzHcUcwY=.0eb96daf-17a6-48e5-923d-e9c20117bec9@github.com>

On Tue, 8 Jul 2025 21:44:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation changes

#mediafeatures works from `Platform.Preferences` and `Scene.Preferences`

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2999219850

From kcr at openjdk.org  Tue Jul  8 23:17:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:17:43 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
Message-ID: <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>

On Wed, 18 Jun 2025 18:34:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This doesn't read like a proper English sentence to me. In Microsoft Word, there's a spinner control titled "Default tab stops:", which I suppose should be read as, for example: "Default tab stops every 0.5 cm".
>> 
>> As for naming the API, I suggest something like `defaultTabWidth` or `defaultWidth` (the word "tab" doesn't need to be repeated, as it's declared in a class named `TabStopPolicy`).
>
> Not sure if defaultTabWidth is a good choice here though, because it's not, it's actually tab stops - think of the typewriter (I know, referring to an ancient technology like floppy disk for the 'save' icon does not age well)
> 
> I am open to suggestions.  I am used to "default tab stops", perhaps we could just explain it better?

Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?

If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:

- defaultStop
- defaultStops
- defaultStopInterval
- Something Else?

I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2193588491

From kcr at openjdk.org  Tue Jul  8 23:17:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:17:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3]
In-Reply-To: <nocHjNTQqEskrC0ITlVfvuXPe4T1duTPkjmU2K4ZtO4=.04991ab9-8d33-4dea-928e-a9faaecabfe3@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com>
 <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com>
 <nocHjNTQqEskrC0ITlVfvuXPe4T1duTPkjmU2K4ZtO4=.04991ab9-8d33-4dea-928e-a9faaecabfe3@github.com>
Message-ID: <yH2vBtFeveTuTsrQd6YgBdMdCT9K6TEzeHLlHxohqt8=.80361439-8031-4785-848e-842bda854fdd@github.com>

On Wed, 18 Jun 2025 18:41:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 67:
>> 
>>> 65:      *
>>> 66:      * @return the default tab stops property
>>> 67:      * @defaultValue 0
>> 
>> Would "8" be a better default value? I think having tabs do something (instead of effectively being ignored) by default when you create a TabStopPolicy would be less surprising to app developers.
>
> No, this value is in pixels (unlike the `tabSize` property).  I think it's better to let the application specify it explicitly.

OK, this seems like a good reason to leave it.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2193589109

From kcr at openjdk.org  Tue Jul  8 23:42:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:42:44 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <R6qFiECAE_QgIUUSPgauBfJIDzlBj_gpxSt_yGWf0qc=.909d7af1-5ffd-45b2-a4be-077d2a68f092@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I left a couple doc comments inline. I'm left wondering if we should do the same thing in Text that you are doing in TextFlow. Namely, deprecate the following four methods, adding getXxxxx methods as replacements:

- hitTest
- caretShape
- rangeShape
- underlineShape

Unlike TextFlow, there is no functional reason we need to do it. So the question is one of consistency. I note that you are already adding one of the four, getRangeShape (to add the lineSpacing parameter). What do you think?

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1092:

> 1090:      * Returns the shape for the range of the text in local coordinates.
> 1091:      * <p>
> 1092:      * NOTE: this shapes returned do not include line spacing.

I would remove the "NOTE:", making it a simple statement (and probably no need for the `<p`> tag), since this is just what the method does.

Question: should this method be deprecated to be consistent with TextFlow?

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 197:

> 195:      * Maps local point to {@link HitInfo} in the content.
> 196:      * <p>
> 197:      * NOTE: this method may return incorrect value with non-empty border or padding.

You should be more explicit, and say that it will not take border or padding into account.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-2999329020
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2193621878
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2193603871

From arapte at openjdk.org  Wed Jul  9 00:04:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Jul 2025 00:04:42 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
Message-ID: <kbzmI6yvwEmDjrWcqwYeviRA8a_-rDdpLu4VybFOGyc=.6439b6f1-c272-462e-b82a-39a8c1371a88@github.com>

On Tue, 8 Jul 2025 20:29:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
>> 
>> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can 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 continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
>> 
>> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - set gradle version min to 8.10.2
>  - 8359387: Bump minimum JDK version for JavaFX to JDK 23

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-2999398915

From kizune at openjdk.org  Wed Jul  9 04:18:47 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:18:47 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
Message-ID: <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>

On Tue, 8 Jul 2025 21:29:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:
> 
>> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
>> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
>> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];
> 
> this change seems unrelated - is it a part of some other work?

When i implemented radio buttons one of the roles this implementation was supposed to fulfill was tab button for the tabbed pane. But without the new implementation of Tab Group it did not work - focus was funky and announcement was not correct. So i commented out this role assignment. When i pushed Tab Group implementation i haven't uncommented this line so now since i do clean up and refactoring on this exact file i tested that now it works properly and uncommented it. Just trying not to spawn too many pull requests for the minimal changes.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193974994

From kizune at openjdk.org  Wed Jul  9 04:23:30 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:23:30 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v2]
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <2HiCNXyevx9srfL4T22am5Vqiej_ZrnG7UY73MHggKc=.07fa1488-b65b-4d43-8c01-3e9aec10dcff@github.com>

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Reverting the curly bracket placement

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1840/files
  - new: https://git.openjdk.org/jfx/pull/1840/files/92c74cbf..9bee13ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=00-01

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

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

From kizune at openjdk.org  Wed Jul  9 04:23:31 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:23:31 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v2]
In-Reply-To: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
Message-ID: <A6-YBNHxfxmYgIjIhUHXUTGG0o1o1GCz24Zi8U8Aerw=.f0eb8a91-c614-460b-a89a-a50a02fa833e@github.com>

On Tue, 8 Jul 2025 21:31:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting the curly bracket placement
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 99:
> 
>> 97: }
>> 98: 
>> 99: - (jobject)getJAccessible {
> 
> should this K&R brace be reverted to the _objectively better_ style used elsewhere in this file?

I would object to objectively - i think this is subjective - but sure, i will fix that :)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193978982

From kizune at openjdk.org  Wed Jul  9 05:01:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 05:01:14 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Remove explicit jresult declaration

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1840/files
  - new: https://git.openjdk.org/jfx/pull/1840/files/9bee13ac..3609f528

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=01-02

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

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

From kizune at openjdk.org  Wed Jul  9 05:01:15 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 05:01:15 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
Message-ID: <vsLA4sNMv4Rdz-uUkDAnS1YTqCQOmCMBjy9fgEqZwHM=.e023ec84-ad7b-499b-9325-e29fc9fc9bce@github.com>

On Tue, 8 Jul 2025 21:33:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove explicit jresult declaration
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 113:
> 
>> 111:     GET_MAIN_JENV;
>> 112:     if (env == NULL) return NULL;
>> 113:     jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible],
> 
> not an expert, but do we really need to initialize `jresult` to NULL in line 110?
> can the variable be declared in line 113 ?

Well this pattern was used to initialize the result value to the default return value so if assignment does not happen due to the Java exception we have something meaningful to return but in case of NULL it is not really required because it will produce the same result anyways.

> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:
> 
>> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
>> 190:     id s = [self requestNodeAttribute:@"AXSize"];
>> 191:     if (p == NULL || s == NULL) {
> 
> not a big issue, but would it be (marginally) better to bail out early if p == NULL ?

But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2194014740
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2194018393

From sykora at openjdk.org  Wed Jul  9 06:14:45 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 9 Jul 2025 06:14:45 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
Message-ID: <laMQ0r73dyBS_bEt-NlwlHBkgX4gq0i1C6zKLLre_vY=.bb06a02f-2c21-44a2-b620-835520c576d8@github.com>

On Tue, 8 Jul 2025 20:29:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
>> 
>> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can 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 continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
>> 
>> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - set gradle version min to 8.10.2
>  - 8359387: Bump minimum JDK version for JavaFX to JDK 23

Marked as reviewed by sykora (Author).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-3000131274

From angorya at openjdk.org  Wed Jul  9 14:59:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 14:59:46 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
Message-ID: <TB0f9Q6iQbUuu4vq59d75kVEWm9w0_iBO_jUUbm6KJE=.d349443b-4841-4a06-8374-a36dca40400a@github.com>

On Wed, 9 Jul 2025 05:01:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove explicit jresult declaration

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1840#pullrequestreview-3001910165

From angorya at openjdk.org  Wed Jul  9 14:59:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 14:59:47 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
Message-ID: <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>

On Wed, 9 Jul 2025 04:15:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:
>> 
>>> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
>>> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
>>> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];
>> 
>> this change seems unrelated - is it a part of some other work?
>
> When i implemented radio buttons one of the roles this implementation was supposed to fulfill was tab button for the tabbed pane. But without the new implementation of Tab Group it did not work - focus was funky and announcement was not correct. So i commented out this role assignment. When i pushed Tab Group implementation i haven't uncommented this line so now since i do clean up and refactoring on this exact file i tested that now it works properly and uncommented it. Just trying not to spawn too many pull requests for the minimal changes.

does it mean we missed something during the testing, something was supposed to work and did not?

since there will be more a-y work, I think it should be ok.

>> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:
>> 
>>> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
>>> 190:     id s = [self requestNodeAttribute:@"AXSize"];
>>> 191:     if (p == NULL || s == NULL) {
>> 
>> not a big issue, but would it be (marginally) better to bail out early if p == NULL ?
>
> But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.

but it will save a couple of nanoseconds!

the code is ok.  one question though: what are the circumstances when these calls would return NULL?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195249304
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195244238

From angorya at openjdk.org  Wed Jul  9 15:28:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:28:08 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v3]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
 - Merge branch 'master' into 8341438.text.shapes.insets
 - cleanup
 - Merge branch 'master' into 8341438.text.shapes.insets
 - layout info
 - tests
 - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
 - cleanup
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - ... and 62 more: https://git.openjdk.org/jfx/compare/639a5950...16ed27eb

-------------

Changes: https://git.openjdk.org/jfx/pull/1817/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=02
  Stats: 556 lines in 5 files changed: 522 ins; 18 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817

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

From angorya at openjdk.org  Wed Jul  9 15:28:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:28:08 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <o5bPPpAytstOHPWlkBoFlQGnbkIy2AMkGY0uIwTOvWA=.19f9150f-628c-4076-b6a0-2e0fd04cc93e@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

> Question: should this method be deprecated to be consistent with TextFlow?

> Namely, deprecate the following four methods, adding getXxxxx methods as replacements

I am open to suggestions, but currently leaning toward leaving `Text` as is.  As you correctly mentioned, it is not functionally required, and would only add more noise.

I feel making `Text` such a heavy object (with properties and all) might have been a design mistake: it would have been much better to use `TextFlow` everywhere, including `Labels`, `TextFields`, and `TextAreas`, and use `Text` as immutable objects similar to `GlyphList` to store runs of characters with the same font and attributes.  Doing so might have allowed easy introduction of rich text into these controls too, but oh well.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3053071927

From angorya at openjdk.org  Wed Jul  9 15:32:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:32:45 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
Message-ID: <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>

On Tue, 8 Jul 2025 23:11:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Not sure if defaultTabWidth is a good choice here though, because it's not, it's actually tab stops - think of the typewriter (I know, referring to an ancient technology like floppy disk for the 'save' icon does not age well)
>> 
>> I am open to suggestions.  I am used to "default tab stops", perhaps we could just explain it better?
>
> Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?
> 
> If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:
> 
> - defaultStop
> - defaultStops
> - defaultStopInterval
> - Something Else?
> 
> I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.

ooh, I like `defaultStopInterval`, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195324654

From kizune at openjdk.org  Wed Jul  9 15:45:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 15:45:52 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
 <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
Message-ID: <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>

On Wed, 9 Jul 2025 14:54:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.
>
> but it will save a couple of nanoseconds!
> 
> the code is ok.  one question though: what are the circumstances when these calls would return NULL?

1. Custom component that has no role assigned at all
2. Exception happens on Java side processing the request
That was just two popped out - probably there are more scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195351917

From angorya at openjdk.org  Wed Jul  9 15:48:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:48:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
 <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
 <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>
Message-ID: <W32hyd3XbTskT5hfipOvWeqrM3E55BcegN9b-do3Tqk=.3e1a427e-d199-4755-98fb-fc92a45286f2@github.com>

On Wed, 9 Jul 2025 15:43:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> but it will save a couple of nanoseconds!
>> 
>> the code is ok.  one question though: what are the circumstances when these calls would return NULL?
>
> 1. Custom component that has no role assigned at all
> 2. Exception happens on Java side processing the request
> That was just two popped out - probably there are more scenarios.

right, thank you for clarification!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195358693

From mfox at openjdk.org  Wed Jul  9 17:23:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 9 Jul 2025 17:23:48 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

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

> 8652:      * @since 26
> 8653:      */
> 8654:     Node getFocusDelegate(Node hoistingNode) {

I tried to tweak the InputMethodStateManager to deal with delegates and discovered there?s no easy way to get a node?s delegate. Shouldn?t there be a public way of retrieving the current delegate?

I don?t think getFocusDelegate should take a parameter. If I was creating a node with multiple focus delegates I would probably want to track the current one in some simple way. But getFocusDelegate doesn?t allow me to do that, I always have to respect the hoisting node parameter being passed in and dig through my descendant nodes to figure out which delegate is being requested. And it implies the only way to change the delegate is to requestFocus on the new delegate and take it through the hoisting process. That seems overly restrictive. I can see why a focus scope node would need to know which node hoisted focus but only at the time the hoist happens.

We?re spending a lot of time thinking about controls that may have more than one delegate. I really doubt anyone will ever create one. If they do it raises a bunch of questions related to accessibility and keyboard traversal that we?re not even discussing.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2195566726

From mstrauss at openjdk.org  Wed Jul  9 17:26:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Jul 2025 17:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
 <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
Message-ID: <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>

On Wed, 9 Jul 2025 15:29:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?
>> 
>> If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:
>> 
>> - defaultStop
>> - defaultStops
>> - defaultStopInterval
>> - Something Else?
>> 
>> I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.
>
> ooh, I like `defaultStopInterval`, thank you.

Maybe make it even shorter and do `TabStopPolicy.defaultInterval`. The reasoning for dropping the "stop" is the same as before, it's already the class name.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195577224

From angorya at openjdk.org  Wed Jul  9 17:26:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 17:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
 <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
 <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>
Message-ID: <k8aIfFL2dOKojstwMmILEPg543D0FErbJBTnnShxtz4=.429c4efe-f290-49c4-bed1-13d2135cbe1d@github.com>

On Wed, 9 Jul 2025 17:23:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> ooh, I like `defaultStopInterval`, thank you.
>
> Maybe make it even shorter and do `TabStopPolicy.defaultInterval`. The reasoning for dropping the "stop" is the same as before, it's already the class name.

even better!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195584151

From kcr at openjdk.org  Wed Jul  9 19:53:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 19:53:43 GMT
Subject: Integrated: 8359387: Bump minimum JDK version for JavaFX to JDK 23
In-Reply-To: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
Message-ID: <dbOMghB98Q-nOtPd_qnNt-uB_Rikkg-m0kKGMqis5sI=.e548f1c3-99d2-4efb-b1a6-5490f9bddd80@github.com>

On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can 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 continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
> 
> This PR targeted to JavaFX 25, 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: 6029e3e4
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6029e3e4058e2a87ecb0f5c07689f7d4783a1c65
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8359387: Bump minimum JDK version for JavaFX to JDK 23

Reviewed-by: arapte, sykora

-------------

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

From kcr at openjdk.org  Wed Jul  9 20:23:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:23:48 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v3]
In-Reply-To: <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>
Message-ID: <qFeFAkZiFnUkAPsls873lia9f-Hu_4VNHC94Hgt3fn0=.29f9a430-48e4-4cfd-ac20-e472c781b3bb@github.com>

On Wed, 9 Jul 2025 15:28:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 62 more: https://git.openjdk.org/jfx/compare/639a5950...16ed27eb

The API and docs look good to me now. I left a minor formatting suggestion for the deprecated methods (use `@link` to point to the replacement methods).

Update the CSR to match, and I'll Review it.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202:

> 200:      * @return a {@code HitInfo} representing the character index found
> 201:      * @since 9
> 202:      * @deprecated replaced by {@code getHitInfo()}

I recommend `@link` here.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 245:

> 243:      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
> 244:      * @since 9
> 245:      * @deprecated replaced by {@code getCaretShape()}

`@link` (here and in. other deprecated methods).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-3002944702
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2195889785
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2195894529

From angorya at openjdk.org  Wed Jul  9 20:27:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:27:07 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - since 25
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - api
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

-------------

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=05
  Stats: 588 lines in 12 files changed: 558 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  9 20:34:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:34:21 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v4]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <9q1cNyuoXi0Zz0xlESAO8QIg-IkhO-hb1_uOKZTQdw8=.b626ca6d-f1b8-42f8-8e1d-9143fb2212d9@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  link

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1817/files
  - new: https://git.openjdk.org/jfx/pull/1817/files/16ed27eb..d466ebc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817

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

From kcr at openjdk.org  Wed Jul  9 20:47:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:47:51 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
Message-ID: <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>

On Wed, 9 Jul 2025 20:27:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - cleanup
>  - api
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

APi looks good with one question and a few working suggestions.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 54:

> 52:      * @return the non-null list of tab stops
> 53:      */
> 54:     public final ObservableList<TabStop> tabStops() {

Did you consider also dropping "tab" from the name here? Either is fine with me, so I'll leave it up to you.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 61:

> 59:      * Specifies the default tab stop interval (beyond the last tab stop provided by {@code #tabStops()}),
> 60:      * as a fixed repeating distance (in pixels) to the next tab stop computed at regular intervals
> 61:      * relative to the leading edge of the {@code TextFlow} node.

This is a bit of a run-on sentence. Maybe consider breaking it up into two sentences, with the detail about "a fixed, repeating distance..." in the second sentence? Something like:


    * Specifies the default tab stop interval for tabs beyond the last stop provided
    * by {@code #tabStops()}. This is a fixed repeating distance (in pixels) to the
    * next tab stop computed at regular intervals relative to the leading edge
    * of the {@code TextFlow} node.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 531:

> 529:      * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> 530:      * with different fonts are contained within this {@code TextFlow}.
> 531:      * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.

either drop the word "the" before "setTabStopPolicy" or add "method" after.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 569:

> 567: 
> 568:     /**
> 569:      * {@code TabStopPolicy} determines the tab stop positions within this {@code TextFlow}.

I think you can remove `{@code TabStopPolicy}` since that's what this property is. Start with "Determines the ..."

-------------

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3003009745
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195925106
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195927394
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195934301
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195937805

From angorya at openjdk.org  Wed Jul  9 20:48:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:48:04 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v5]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1817/files
  - new: https://git.openjdk.org/jfx/pull/1817/files/d466ebc9..a2099f02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817

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

From kcr at openjdk.org  Wed Jul  9 20:50:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:50:46 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
Message-ID: <FgYaYhly6ot92G9LvvRy0ejnqcxXy_1mVL9Go1240vs=.d596ad30-5560-46d1-a9b1-6c516233a1b9@github.com>

On Wed, 9 Jul 2025 20:27:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - cleanup
>  - api
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 68:

> 66:      * @defaultValue 0
> 67:      */
> 68:     public final DoubleProperty defaultInterval() {

Oops. This should be `defaultIntervalProperty()`, which explains the GHA build failure.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195944153

From angorya at openjdk.org  Wed Jul  9 21:08:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:08:00 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v7]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  oops

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1744/files
  - new: https://git.openjdk.org/jfx/pull/1744/files/00bcf4b0..9851c92d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=05-06

  Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  9 21:08:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:08:01 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
 <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>
Message-ID: <Wr3pnip9yAWQ-EvetuN_3P3apHTQJqezzR-FQpIXLrc=.458ad2b7-e14a-4343-978a-123349c13892@github.com>

On Wed, 9 Jul 2025 20:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
>> 
>>  - since 25
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - final tab stop
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - cleanup
>>  - api
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 54:
> 
>> 52:      * @return the non-null list of tab stops
>> 53:      */
>> 54:     public final ObservableList<TabStop> tabStops() {
> 
> Did you consider also dropping "tab" from the name here? Either is fine with me, so I'll leave it up to you.

I prefer `tabStops`.

> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 61:
> 
>> 59:      * Specifies the default tab stop interval (beyond the last tab stop provided by {@code #tabStops()}),
>> 60:      * as a fixed repeating distance (in pixels) to the next tab stop computed at regular intervals
>> 61:      * relative to the leading edge of the {@code TextFlow} node.
> 
> This is a bit of a run-on sentence. Maybe consider breaking it up into two sentences, with the detail about "a fixed, repeating distance..." in the second sentence? Something like:
> 
> 
>     * Specifies the default tab stop interval for tabs beyond the last stop provided
>     * by {@code #tabStops()}. This is a fixed repeating distance (in pixels) to the
>     * next tab stop computed at regular intervals relative to the leading edge
>     * of the {@code TextFlow} node.

much better, thank you!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195966406
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195968373

From kcr at openjdk.org  Wed Jul  9 21:26:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 21:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v7]
In-Reply-To: <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>
Message-ID: <mE0AUFk9xlV6_TPQgMDXr3FiukPEoz78KGDvCvPO4y8=.c632caf0-c16c-4907-b793-5b1786837c7a@github.com>

On Wed, 9 Jul 2025 21:08:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oops

API / docs looks good with one formatting issue that I noticed when looking at the generated API docs.

I'll review the CSR next.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60:

> 58:     /**
> 59:      * Specifies the default tab stop interval for tabs beyond the last stop provided
> 60:      * by {@code #tabStops()}.  This is a fixed repeating distance (in pixels) to the

Change this to a `@link` or remove the `#` and `()` since they show up in the docs.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3003151060
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2196012493

From angorya at openjdk.org  Wed Jul  9 21:30:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:30:59 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v8]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  link

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1744/files
  - new: https://git.openjdk.org/jfx/pull/1744/files/9851c92d..2a1e479b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  9 21:43:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:43:46 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v8]
In-Reply-To: <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>
Message-ID: <ho8tSKDGKv44PSJ5erWxAlLkgDDCGnajDF8p1gfXTfY=.3893827a-3ed3-4d85-87bb-db318730bbed@github.com>

On Wed, 9 Jul 2025 21:30:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link

created the CSR.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-3054161142

From angorya at openjdk.org  Wed Jul  9 22:45:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 22:45:52 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v5]
In-Reply-To: <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
Message-ID: <4pnPG_GZAI6fcSeKFMYV7yr2-83JJlI_ORFH_iaJfDU=.3f24ad97-f2fb-460d-b471-9bf2c39325a4@github.com>

On Wed, 9 Jul 2025 20:48:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

Made https://bugs.openjdk.org/browse/JDK-8357594 to be the main issue, closed https://bugs.openjdk.org/browse/JDK-8341438 as a duplicate of JDK-8357594 .

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3054323225