From mfox at openjdk.org  Thu May  1 02:30:54 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 1 May 2025 02:30:54 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
Message-ID: <yF49yc_euKfb6c-Q68p0FyXSvhKTCZI7UvDNL6B7CPs=.6ae603e2-bae0-4fa8-8291-e53e6835cba1@github.com>

On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

For what it's worth the failure of testDemaximizedPosition is due to old behavior captured in [JDK-8355990](https://bugs.openjdk.org/browse/JDK-8355990). During the maximize transition glass sends out a slew of position updates. This test can capture any one of these notifications and trigger the latch indicating that the transition is done. I've already put together a fix and will re-visit this test when I submit that PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2843943333

From kcr at openjdk.org  Thu May  1 11:01:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 11:01:05 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
Message-ID: <YtrXCpyrkJxf7AbWL7xQV3_EwbzqmJPdY5NucrvATas=.f16960a4-27dc-4836-b5b2-22579135930b@github.com>

On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

Thanks for the explanation. I didn't actually look at the tests in this PR or I would have seen that the failure was in a formerly-disabled test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2844643752

From pavelturk2000 at gmail.com  Thu May  1 12:40:23 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 1 May 2025 15:40:23 +0300
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
Message-ID: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>

I've just found out that RichTextArea doesn't have a setText method, but CodeArea does.

Is this a mistake or was it done intentionally?

Best regards, Pavel

PS. Just don't think I spend my free time analyzing Javadoc. It's just that I once opened an issue in RTFX suggesting
to add a setText method, and today, seeing this issue, I decided to mention that JavaFX RichTextArea has such
a method. However, I was surprised not to find it.



From tsayao at openjdk.org  Thu May  1 12:35:37 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 1 May 2025 12:35:37 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v10]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <FOUeg3yNbdTl1mWpQk6oWi4dfNEPfl8wobv4406TZ78=.d16d2064-1e09-442b-bda4-fb1e55a915b2@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is also provided but I would prefer to move it's functionality to monkey tester:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 2. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.o...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Use GDK for windowing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/61230d59..61b7593d

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

  Stats: 1899 lines in 13 files changed: 1093 ins; 531 del; 275 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Thu May  1 13:23:43 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 1 May 2025 13:23:43 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v11]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <TwKdOd8RhyFsXeDLTKE5MjL212XLcRaEXp8Q5i3rENA=.a6246d8d-4227-4c54-9ad3-ea45e7253cdf@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remove state precedence tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/61b7593d..0b3cd300

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=09-10

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

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

From tsayao at openjdk.org  Thu May  1 13:23:44 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 1 May 2025 13:23:44 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <v15yEIMhm7PNBq5QdBoEjwajc_mAjZniL0crRzWCc1o=.0ca59373-dd4e-4ae8-a977-57d5f36b857e@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
 <v15yEIMhm7PNBq5QdBoEjwajc_mAjZniL0crRzWCc1o=.0ca59373-dd4e-4ae8-a977-57d5f36b857e@github.com>
Message-ID: <ns_T3uke728Og53piwa8a-7gzWc6w31swgI8cMzt5OM=.775ea279-6943-4aa0-9628-fc192dd8c770@github.com>

On Thu, 24 Apr 2025 22:43:17 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/stage/FullScreenTest.java line 123:
>> 
>>> 121:             mode = EnumSource.Mode.INCLUDE,
>>> 122:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>>> 123:     void testUnFullScreenChangedSize(StageStyle stageStyle) {
>> 
>> According to the spec changes to the size or position of a window while it's in fullscreen mode will be ignored and applied after the window leaves fullscreen mode. That's not how it currently works on macOS or Windows 11. Actually implementing that part of the spec would be complicated and probably not worth the development cycles. I would rather remove that wording and drop the testUnFullScreenChangeSize and Position tests.
>> 
>> I imagine this was easy to implement back when fullscreen was implemented as a separate window. It's not clear this is useful behavior, the spec might just have captured an implementation detail and elevated it to a feature.
>
> I was kind of on the fence with this one. Maybe it?s a case where the docs in Stage.java need fixing ? they do also say that width and height should reflect the unfullscreened size. But there are several tests that check the fullscreen size against the screen size, so I opted for notifying the fullscreen sizes.

I have removed the behavior and now it just ignores the sizing/position requests.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2070260788

From tsayao at openjdk.org  Thu May  1 13:23:46 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 1 May 2025 13:23:46 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v9]
In-Reply-To: <8xPy_DAa_f26DcpvFwoBc82uXGsQHejDI55bpbrIfK8=.8d871d7a-6569-44c4-92eb-7ed413f16616@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>
 <8xPy_DAa_f26DcpvFwoBc82uXGsQHejDI55bpbrIfK8=.8d871d7a-6569-44c4-92eb-7ed413f16616@github.com>
Message-ID: <oro_9KS-ven3y6syTXWY9FWL60Dwd_XcccSeyfAMP34=.2f2c4ce9-5575-47ca-8f43-e7d616a67a33@github.com>

On Tue, 29 Apr 2025 18:46:39 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove old comment
>
> tests/system/src/test/java/test/robot/javafx/stage/StageAttributesTest.java line 312:
> 
>> 310:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>> 311:     @EnumSource(names = {"DECORATED", "UNDECORATED"})
>> 312:     void testStageStatePrecedenceOrderIconifiedMaximizedBeforeShow(StageStyle stageStyle) throws InterruptedException {
> 
> The precedence rules written into the spec are very problematic and it would be a bear to implement them. For example, if you attempt to maximize an iconified stage on Windows it will de-iconify. Making it stay iconified and maximize later would take real effort. Maximizing an iconified stage on Mac does nothing (glass loses the maximized state) and fixing that would also take a lot of work. I really think our time would be better spent leaving things as-is and updating the spec.
> 
> I don't think the API calls for maximizing and iconifying the stage are useful to begin with. These are features provided to users so they can manager their desktop real estate. There's not a lot of compelling use cases for apps to do this.

I agree we should do an update on the documentation and accept that platforms differ on some aspects (that are acceptable) such as this one.

Maximize maybe there's the case to start maximized to cover the screen for single-application use machines (common in enterprise software). I don't see the use for iconify.

I have removed this test and the related ones that test state precedence order.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2070259389

From angorya at openjdk.org  Thu May  1 14:36:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 May 2025 14:36:50 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
Message-ID: <KiLbEY__A5hCgZKi_H-sNoT9FTDiqVdVY16wA8HoFSY=.e83b0228-9dc3-4b97-ba46-f6ff403d10fa@github.com>

On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1797#pullrequestreview-2809927486

From andy.goryachev at oracle.com  Thu May  1 14:55:26 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 1 May 2025 14:55:26 +0000
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
In-Reply-To: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
References: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
Message-ID: <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>

Intentionally: the CodeArea model contains plain text, while in the RichTextArea the content depends on the model.  It may not contain anything and be generated on the fly.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 1, 2025 at 05:40
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea: RichTextArea doesn't have a setText method, but CodeArea does
I've just found out that RichTextArea doesn't have a setText method, but CodeArea does.

Is this a mistake or was it done intentionally?

Best regards, Pavel

PS. Just don't think I spend my free time analyzing Javadoc. It's just that I once opened an issue in RTFX suggesting
to add a setText method, and today, seeing this issue, I decided to mention that JavaFX RichTextArea has such
a method. However, I was surprised not to find it.

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

From kcr at openjdk.org  Thu May  1 13:57:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 13:57:49 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <xK-TpgHp9PGYGpwMiZ3Q2LPT4UJvv4_cXoxW7bomUmE=.a9363977-799d-4e33-9f86-63fecdbcb409@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <dWWdm42_W2BakDJ1psKgrHweCi4ORNejV2j5yu_H-dU=.21758034-390c-4709-aed2-a8f8749d3884@github.com>
 <xK-TpgHp9PGYGpwMiZ3Q2LPT4UJvv4_cXoxW7bomUmE=.a9363977-799d-4e33-9f86-63fecdbcb409@github.com>
Message-ID: <pZr0Bwyde1fKc2oItm8CzjsZ0Kwf3U2UEdQQVxuuM9w=.49066cf1-eb19-48f6-9d47-48673ad84ac4@github.com>

On Wed, 30 Apr 2025 21:53:38 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> I setup an Ubuntu 24.04.2 LTS inside WSL, did export GDK_BACKEND=x11 (otherwise I always got a crash).

Interesting. The crash is likely due to [JDK-8340378](https://bugs.openjdk.org/browse/JDK-8340378). JavaFX glass calls `putenv("GDK_BACKEND=x11")` at initialization time, but this is likely too late in the case where FXCanvas is embedded in an SWT window. By that time SWT has already initialized the Gtk toolkit, so the env variable needs to be set earlier.

I will check whether this is the case by trying out HelloFXCanvas after first setting that variable. If so, then the fix for [JDK-8340378](https://bugs.openjdk.org/browse/JDK-8340378) will be to set that env variable from HelloFXCanvas when running on Linux.

Getting back to this PR For the fix will likely be to modify the test to set that env variable when running on Linux. Although, that presumes the test is stable across multiple Linux platforms.

> The tests are always green for me. Tried several times.

Since it works for you on Ubuntu 24.04, the failures I see might be specific to 22.04. We don't have a good way to check specific versions of Ubuntu Linux. I'll retest this when I have time to check the Wayland workaround on 24.04 and let you know.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2844889943

From tsayao at openjdk.org  Thu May  1 14:50:15 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 1 May 2025 14:50:15 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v12]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <kkVlWiXINArtaFkv_7u6Ufi0gvpVHDJfEwMhG-2t94o=.3d61d69a-4fc7-455f-b9ff-dbca35040993@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix test on SizingTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/0b3cd300..d25ea134

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=10-11

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From kcr at openjdk.org  Thu May  1 15:18:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 15:18:53 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
Message-ID: <vD1dQBcdNL_pEnyW7wLgrrbL7mvBXD3AHEC82WwZr3A=.ae8a4623-177a-4d8f-b5a6-f24be454ecd6@github.com>

On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

The code changes look good and all my testing looks good. I left a question about some possible additional testing, but I don't consider it directly related to this PR. It could be done as a follow-up if there is a concern.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1797#pullrequestreview-2810011315

From kcr at openjdk.org  Thu May  1 15:30:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 15:30:49 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <1kF9UNp2Z7dEE9kHOdc6OWP3rgXOVn_giVDzuBm1U6I=.79dd7a10-9024-46d0-9469-cdadb9614ff0@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

The fix looks good. I can confirm the problem using a simple variant of HellofullScreenToggle and an UNDECORATED stage. It works as expected now.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1799#pullrequestreview-2810037964

From kcr at openjdk.org  Thu May  1 15:18:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 15:18:53 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <nGEG7kAQL-iQH24GFTU9cKfSolbKA2n8LYMX334g2Q4=.470d2d71-85c8-4964-9818-6aef513a0c7b@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <yyNaXtpucgqZS8jlwgjJL-uU1PzfumatXULRhVSytVM=.bebdbcf4-0f86-47ec-9f6b-e95b3d713590@github.com>
 <nGEG7kAQL-iQH24GFTU9cKfSolbKA2n8LYMX334g2Q4=.470d2d71-85c8-4964-9818-6aef513a0c7b@github.com>
Message-ID: <sv350UoCHcLditCqRJzgrLHvsJsu6Hr-0TmxBiFDbc8=.f78b9522-7e64-4c02-9957-b0fad28b7b14@github.com>

On Tue, 29 Apr 2025 16:40:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > * Will there be any problem one of the deferred Runnables causes an exitFullScreen (e.g., on a different Stage in a dual screen case)? This might be worth testing.
> 
> Could you provide more details on what you want tested? I'm not that familiar with how fullscreen works on dual screen setups.

My thought was to do something like this on a dual-monitor system:

1. Create two stages, one on each screen
2. Programmatically enter full-screen in both Windows from the same block (e.g., the same `runLater`)
3. Sleep until animation finishes
4. Programmatically exit full-screen in both Windows from the same block (e.g., the same `runLater`)
5. Sleep until animation finishes
6. Repeat steps 2-5 but this time from different runLater runnables
7. Programmatically enter full-screen in stage1
8. Sleep until animation finishes
9. Programmatically enter full-screen in stage2
10. While stage2 is still animating its full-screen-enter, programmatically exit full screen in stage1.

If there is a problem, it likely exists today. I doubt this PR will make it worse, but I wanted to at least bring it up as a thought experiment.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2845042296

From kevin.rushforth at oracle.com  Thu May  1 17:32:55 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 1 May 2025 10:32:55 -0700
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
In-Reply-To: <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
 <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <d5c813a8-afc3-4f5e-8601-de2afd119439@oracle.com>

Note that there is an easy way to set plain text if you are using a 
writable model:

rta.clear();
rta.appendText(String text);

-- Kevin


On 5/1/2025 7:55 AM, Andy Goryachev wrote:
>
> Intentionally: the CodeArea model contains plain text, while in the 
> RichTextArea the content depends on the model.? It may not contain 
> anything and be generated on the fly.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 1, 2025 at 05:40
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *RichTextArea: RichTextArea doesn't have a setText method, 
> but CodeArea does
>
> I've just found out that RichTextArea doesn't have a setText method, 
> but CodeArea does.
>
> Is this a mistake or was it done intentionally?
>
> Best regards, Pavel
>
> PS. Just don't think I spend my free time analyzing Javadoc. It's just 
> that I once opened an issue in RTFX suggesting
> to add a setText method, and today, seeing this issue, I decided to 
> mention that JavaFX RichTextArea has such
> a method. However, I was surprised not to find it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250501/dc2de0d7/attachment.htm>

From pavelturk2000 at gmail.com  Thu May  1 17:41:27 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 1 May 2025 20:41:27 +0300
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
In-Reply-To: <d5c813a8-afc3-4f5e-8601-de2afd119439@oracle.com>
References: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
 <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>
 <d5c813a8-afc3-4f5e-8601-de2afd119439@oracle.com>
Message-ID: <dcccf6b1-f2a4-4dd8-9671-b841f1427ded@gmail.com>

To be honest, I think this will create problems when working with the RichTextArea API.

Why? Because every developer will intuitively look for setText. For example, TextArea
?https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TextArea.html ?
has setText. CodeArea has setText. But RichTextArea doesn't.

This doesn't seem very good. But that's just my personal opinion.

Best regards, Pavel

On 5/1/25 20:32, Kevin Rushforth wrote:
> Note that there is an easy way to set plain text if you are using a writable model:
>
> rta.clear();
> rta.appendText(String text);
>
> -- Kevin
>
>
> On 5/1/2025 7:55 AM, Andy Goryachev wrote:
>>
>> Intentionally: the CodeArea model contains plain text, while in the RichTextArea the content depends on the model.? It may not contain anything and be generated on the fly.
>>
>> -andy
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
>> *Date: *Thursday, May 1, 2025 at 05:40
>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>> *Subject: *RichTextArea: RichTextArea doesn't have a setText method, but CodeArea does
>>
>> I've just found out that RichTextArea doesn't have a setText method, but CodeArea does.
>>
>> Is this a mistake or was it done intentionally?
>>
>> Best regards, Pavel
>>
>> PS. Just don't think I spend my free time analyzing Javadoc. It's just that I once opened an issue in RTFX suggesting
>> to add a setText method, and today, seeing this issue, I decided to mention that JavaFX RichTextArea has such
>> a method. However, I was surprised not to find it.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250501/d2237f93/attachment-0001.htm>

From kevin.rushforth at oracle.com  Thu May  1 17:43:41 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 1 May 2025 10:43:41 -0700
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
In-Reply-To: <dcccf6b1-f2a4-4dd8-9671-b841f1427ded@gmail.com>
References: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
 <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>
 <d5c813a8-afc3-4f5e-8601-de2afd119439@oracle.com>
 <dcccf6b1-f2a4-4dd8-9671-b841f1427ded@gmail.com>
Message-ID: <64336c73-cb84-4a73-aee5-ddb1158bb341@oracle.com>

It would be easy enough to add one as a convenience method, if it was 
deemed useful enough. Andy can comment further.

-- Kevin

On 5/1/2025 10:41 AM, PavelTurk wrote:
> To be honest, I think this will create problems when working with the 
> RichTextArea API.
>
> Why? Because every developer will intuitively look for setText. For 
> example, TextArea
> ?https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TextArea.html 
> ?
> has setText. CodeArea has setText. But RichTextArea doesn't.
>
> This doesn't seem very good. But that's just my personal opinion.
>
> Best regards, Pavel
>
> On 5/1/25 20:32, Kevin Rushforth wrote:
>> Note that there is an easy way to set plain text if you are using a 
>> writable model:
>>
>> rta.clear();
>> rta.appendText(String text);
>>
>> -- Kevin
>>
>>
>> On 5/1/2025 7:55 AM, Andy Goryachev wrote:
>>>
>>> Intentionally: the CodeArea model contains plain text, while in the 
>>> RichTextArea the content depends on the model.? It may not contain 
>>> anything and be generated on the fly.
>>>
>>> -andy
>>>
>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>>> PavelTurk <pavelturk2000 at gmail.com>
>>> *Date: *Thursday, May 1, 2025 at 05:40
>>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>> *Subject: *RichTextArea: RichTextArea doesn't have a setText method, 
>>> but CodeArea does
>>>
>>> I've just found out that RichTextArea doesn't have a setText method, 
>>> but CodeArea does.
>>>
>>> Is this a mistake or was it done intentionally?
>>>
>>> Best regards, Pavel
>>>
>>> PS. Just don't think I spend my free time analyzing Javadoc. It's 
>>> just that I once opened an issue in RTFX suggesting
>>> to add a setText method, and today, seeing this issue, I decided to 
>>> mention that JavaFX RichTextArea has such
>>> a method. However, I was surprised not to find it.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250501/50f93ac6/attachment.htm>

From andy.goryachev at oracle.com  Thu May  1 17:49:34 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 1 May 2025 17:49:34 +0000
Subject: RichTextArea: RichTextArea doesn't have a setText method, but
 CodeArea does
In-Reply-To: <dcccf6b1-f2a4-4dd8-9671-b841f1427ded@gmail.com>
References: <2b346355-b3ac-4a91-b5a4-fab9ae4846f5@gmail.com>
 <BYAPR10MB3013B4DBD10400C74000E80BE5822@BYAPR10MB3013.namprd10.prod.outlook.com>
 <d5c813a8-afc3-4f5e-8601-de2afd119439@oracle.com>
 <dcccf6b1-f2a4-4dd8-9671-b841f1427ded@gmail.com>
Message-ID: <BYAPR10MB301391F4F7EE4FED0606CB6DE5822@BYAPR10MB3013.namprd10.prod.outlook.com>

This API is designed specifically not to confuse - there is no "text" property in RichTextArea, cannot be.  There is the "model" property, and the corresponding setModel().  It is different with the CodeArea because the CodeModel does operate with (decorated) plain text.

Additionally, the end result of clear/appendText/replaceText/insertText might depend on the existing paragraph attributes.

It's the same reason we don't have setText() in the TextFlow.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 1, 2025 at 10:41
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: RichTextArea doesn't have a setText method, but CodeArea does
To be honest, I think this will create problems when working with the RichTextArea API.

Why? Because every developer will intuitively look for setText. For example, TextArea
?https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TextArea.html ?
has setText. CodeArea has setText. But RichTextArea doesn't.

This doesn't seem very good. But that's just my personal opinion.

Best regards, Pavel
On 5/1/25 20:32, Kevin Rushforth wrote:
Note that there is an easy way to set plain text if you are using a writable model:

rta.clear();
rta.appendText(String text);

-- Kevin

On 5/1/2025 7:55 AM, Andy Goryachev wrote:
Intentionally: the CodeArea model contains plain text, while in the RichTextArea the content depends on the model.  It may not contain anything and be generated on the fly.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 1, 2025 at 05:40
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RichTextArea: RichTextArea doesn't have a setText method, but CodeArea does
I've just found out that RichTextArea doesn't have a setText method, but CodeArea does.

Is this a mistake or was it done intentionally?

Best regards, Pavel

PS. Just don't think I spend my free time analyzing Javadoc. It's just that I once opened an issue in RTFX suggesting
to add a setText method, and today, seeing this issue, I decided to mention that JavaFX RichTextArea has such
a method. However, I was surprised not to find it.


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

From kcr at openjdk.org  Thu May  1 18:56:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 18:56:02 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v16]
In-Reply-To: <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ZIaXEMTbtzvZ8arXaFwUH5bp0-ubCsEvmx_NawNDuN4=.114e6bd5-1df2-4c49-805c-12a13512fb68@github.com>
 <koMHkh-j6oEyEkfkggbpNlwub3pGwXy7FIwZCA7KKRc=.0f9ae1b7-4e0c-4722-913b-e6fbffb6a379@github.com>
 <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
Message-ID: <qweSx89p4xGaNd5hM6MAvrqeq8ecLagZMUsGNwlcU6M=.4899dca0-b41c-47e5-a8c2-84c720192365@github.com>

On Wed, 5 Feb 2025 21:18:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91:
>> 
>>> 89:      * @return the immutable list of {@code Rectangle2D} objects
>>> 90:      */
>>> 91:     public abstract List<Rectangle2D> selectionShape(int start, int end, boolean includeLineSpacing);
>> 
>> See my comment below about using `javafx.scene.shape.Rectangle` instead of `javafx.geometry.Rectangle2D`: otherwise the API is misleading: `selectionShape` doesn't return a `Shape` subclass.
>
> Good point.  The word 'shape' might be confusing, although it is still correct in human terms (it is a shape, after all).  I think it's ok, but we could use the word "geometry" for these methods `selectionGeometry` / `strikeThroughGeometry` / `underlineGeometry`, what do other people think?
> 
> As for using `javafx.scene.shape.Rectangle` - it is too heavy of an object, with properties and everything, it's not what we ask from this method.

Yeah, it might be better to use a different name. "geometry" seems fine to me. Or maybe "bounds" although it's a list of bounds, so that's a little less clear. I like "geometry" the best so far.

If we do this, then you could even add the "get" at the beginning of the name (as suggested by Michael), since it would no longer duplicate the equivalent name in Text/TextFlow. I don't have a strong opinion either way on this one.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070609419

From angorya at openjdk.org  Thu May  1 19:13:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 May 2025 19:13:53 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v16]
In-Reply-To: <qweSx89p4xGaNd5hM6MAvrqeq8ecLagZMUsGNwlcU6M=.4899dca0-b41c-47e5-a8c2-84c720192365@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ZIaXEMTbtzvZ8arXaFwUH5bp0-ubCsEvmx_NawNDuN4=.114e6bd5-1df2-4c49-805c-12a13512fb68@github.com>
 <koMHkh-j6oEyEkfkggbpNlwub3pGwXy7FIwZCA7KKRc=.0f9ae1b7-4e0c-4722-913b-e6fbffb6a379@github.com>
 <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
 <qweSx89p4xGaNd5hM6MAvrqeq8ecLagZMUsGNwlcU6M=.4899dca0-b41c-47e5-a8c2-84c720192365@github.com>
Message-ID: <coNxkkS25y6Urtpk3DqFl36GmUulNDip0UEL0hULl6E=.3a81050d-efc6-4dd4-b4db-d44d1d3028e5@github.com>

On Thu, 1 May 2025 18:13:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Good point.  The word 'shape' might be confusing, although it is still correct in human terms (it is a shape, after all).  I think it's ok, but we could use the word "geometry" for these methods `selectionGeometry` / `strikeThroughGeometry` / `underlineGeometry`, what do other people think?
>> 
>> As for using `javafx.scene.shape.Rectangle` - it is too heavy of an object, with properties and everything, it's not what we ask from this method.
>
> Yeah, it might be better to use a different name. "geometry" seems fine to me. Or maybe "bounds" although it's a list of bounds, so that's a little less clear. I like "geometry" the best so far.
> 
> If we do this, then you could even add the "get" at the beginning of the name (as suggested by Michael), since it would no longer duplicate the equivalent name in Text/TextFlow. I don't have a strong opinion either way on this one.

I like the idea of `getX*Geometry()`, to further distance the new API from the buggy ones in `Text`/`TextFlow`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070680024

From kcr at openjdk.org  Thu May  1 18:56:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 18:56:01 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <qnJu1fSsF8HLFFXKqz-cnXmdf5781GfbVSEFA7kW7Yk=.7abc99c7-7f9b-441a-b388-ae9852e66786@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
 <rexLOJ6STpt-XPKlKlta2CPdhCuSKAtXaJAbpxad-7E=.6ead5778-7c2a-40c8-91ab-171dd90da53f@github.com>
 <qnJu1fSsF8HLFFXKqz-cnXmdf5781GfbVSEFA7kW7Yk=.7abc99c7-7f9b-441a-b388-ae9852e66786@github.com>
Message-ID: <pmpU0cyCiSXJtUDgByB-bNirUnaeT2vJD9Cf4NfBwLs=.e87e7c50-1fde-4976-bed7-5480ce56221d@github.com>

On Mon, 7 Apr 2025 19:14:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> `TextLineInfo` is a record, I don't want to add duplicate getXXX() aliases there.
>> 
>> The other (in `LayoutInfo`) are modeled after `Text`/`TextFlow` (e.g. `underlineShape()`), I have no problem with any of these.  I don't think we have strict rules regarding naming, and these are not java beans to utilize some sort of naming pattern in accessors, but I could be missing something.
>> 
>> Could you be more specific?
>
> I understand the argument for `TextLineInfo`, I guess I'm looking more at `LayoutInfo` here. My question is whether it is really the best choice to sacrifice local consistency within a single class just to have it look more similar to equally inconsistently named methods in another class? Anyway, I just wanted to point this out, that's not a hill for me to die on.

Is the "thickness" of the returned `Rectangle2D` significant? Typically this is a line, meaning that width would be 0 for horizontal text. I presume that the width can be > 0 and that it would do what you expect?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070422202

From kcr at openjdk.org  Thu May  1 19:01:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 19:01:57 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
Message-ID: <eZEEH_DKEpNwC8C0i7mfFYzkF1KGZ85QOQuAQqfTuT8=.1e2259a6-4337-441c-be9f-84c8b12e8974@github.com>

On Mon, 7 Apr 2025 19:37:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sealed

modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 60:

> 58:      * @return the bounds of the caret segment
> 59:      * @throws IndexOutOfBoundsException if the index is out of range
> 60:      *     {@code (index < 0 || index > getSegmentCount())}

Shouldn't this be `>= getSegmentCount()`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070658522

From mstrauss at openjdk.org  Thu May  1 19:39:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 1 May 2025 19:39:55 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <Sq7azHv-3b5ToybvIFhbRrcpII4FkSXGJPoEElwp9TU=.3b97927c-b555-4ac4-a2d4-b3e51490bf35@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
 <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>
 <yNhTOh9Rhs9dXMrWcINpz-RPRq2xwoKDq_URx7hyycI=.781b4b58-426e-4b27-95ad-dce396692deb@github.com>
 <Sq7azHv-3b5ToybvIFhbRrcpII4FkSXGJPoEElwp9TU=.3b97927c-b555-4ac4-a2d4-b3e51490bf35@github.com>
Message-ID: <3xo2gQnz1qZmIYAp3mHp0bmlCTnYnofDME_RlkU_zF4=.99874a60-e40f-420b-a471-6ee8356a733d@github.com>

On Thu, 1 May 2025 19:20:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> More importantly, you need `</li`> tags after each item. As it is, I doubt it would pass "tidy".
>
> what's a "tidy" and is it a part of our build/validation?

The closing `</li>` tag is not required in HTML, and Javadoc doesn't seem to object. Is this a requirement of another tool? We're using `<li>` without a closing tag in many places in JavaFX.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070707622

From angorya at openjdk.org  Thu May  1 19:22:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 May 2025 19:22:57 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <yNhTOh9Rhs9dXMrWcINpz-RPRq2xwoKDq_URx7hyycI=.781b4b58-426e-4b27-95ad-dce396692deb@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
 <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>
 <yNhTOh9Rhs9dXMrWcINpz-RPRq2xwoKDq_URx7hyycI=.781b4b58-426e-4b27-95ad-dce396692deb@github.com>
Message-ID: <Sq7azHv-3b5ToybvIFhbRrcpII4FkSXGJPoEElwp9TU=.3b97927c-b555-4ac4-a2d4-b3e51490bf35@github.com>

On Thu, 1 May 2025 15:50:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> in this economy, spaces are expensive ;-)
>
> More importantly, you need `</li`> tags after each item. As it is, I doubt it would pass "tidy".

what's a "tidy" and is it a part of our build/validation?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070690086

From kcr at openjdk.org  Thu May  1 18:56:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 18:56:03 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
 <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>
Message-ID: <yNhTOh9Rhs9dXMrWcINpz-RPRq2xwoKDq_URx7hyycI=.781b4b58-426e-4b27-95ad-dce396692deb@github.com>

On Fri, 11 Apr 2025 15:00:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TextLineInfo.java line 36:
>> 
>>> 34:  * @param bounds the bounds of the text line, in local coordinates:
>>> 35:  * <ul>
>>> 36:  *   <li>
>> 
>> We usually indent with 4 spaces.
>
> in this economy, spaces are expensive ;-)

More importantly, you need `</li`> tags after each item. As it is, I doubt it would pass "tidy".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070435920

From kcr at openjdk.org  Thu May  1 19:55:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 19:55:55 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <3xo2gQnz1qZmIYAp3mHp0bmlCTnYnofDME_RlkU_zF4=.99874a60-e40f-420b-a471-6ee8356a733d@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <vhqd2EYA5HkHqVOAIEHz2d-0fwfq8Q8Ra18mTSL-awc=.30ff17ab-94eb-4c1f-9991-78e88c340699@github.com>
 <gYc9xZaADtslU2RyrSGLZzz_J-7GjFKHn80SDk7l2lg=.0a39066e-4847-405f-acc9-2fe100b7ab68@github.com>
 <yNhTOh9Rhs9dXMrWcINpz-RPRq2xwoKDq_URx7hyycI=.781b4b58-426e-4b27-95ad-dce396692deb@github.com>
 <Sq7azHv-3b5ToybvIFhbRrcpII4FkSXGJPoEElwp9TU=.3b97927c-b555-4ac4-a2d4-b3e51490bf35@github.com>
 <3xo2gQnz1qZmIYAp3mHp0bmlCTnYnofDME_RlkU_zF4=.99874a60-e40f-420b-a471-6ee8356a733d@github.com>
Message-ID: <vdtPFbnIN9EAH5doVVwqUBUCzgzEYS64qOEOHKnFBPg=.7c2e4e65-0915-4aa6-8c65-44f1ab1926f7@github.com>

On Thu, 1 May 2025 19:36:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> what's a "tidy" and is it a part of our build/validation?
>
> The closing `</li>` tag is not required in HTML, and Javadoc doesn't seem to object. Is this a requirement of another tool? We're using `<li>` without a closing tag in many places in JavaFX.

OK. I (mistakenly) thought that this was required. To answer Andy's question, [tidy](https://www.html-tidy.org/) is a tool to validate HTML5 for various formatting problems which can cause problems with some browsers. The JDK team used to periodically run it on their javadoc, but I don't think it is run continuously. Jon Gibbons filed [JDK-8184220](https://bugs.openjdk.org/browse/JDK-8184220) several years ago to "tidy" up our docs, which we did. This did not flag any missing `</li>` tags.

So: no change needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070723910

From duke at openjdk.org  Thu May  1 19:59:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 1 May 2025 19:59:54 GMT
Subject: Withdrawn: 8345261: Refactor the Dimension2D classes
In-Reply-To: <YrGqPSWSFSNx2H-1ZfkyrTILFMExj6q-_sfWlhzI-hQ=.782d35d8-01b7-417b-ae17-d824812b5c7e@github.com>
References: <YrGqPSWSFSNx2H-1ZfkyrTILFMExj6q-_sfWlhzI-hQ=.782d35d8-01b7-417b-ae17-d824812b5c7e@github.com>
Message-ID: <f2pli4RhiKGWiHUPWXg1A7aQrU_8jGXWscgijEbBPE4=.b139b308-b711-4c2a-8608-1e89ddda732c@github.com>

On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A small refactoring of the Dimension classes.
> 
> * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`.
> * `com.sun.javafx.geom.Dimension2D` became a record.
> * `javafx.geometry.Dimension2D`: fields became `final`.
> 
> I'm not sure we need the implementation class at all considering we are free to use the public one.

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Thu May  1 18:56:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 18:56:00 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
Message-ID: <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>

On Mon, 7 Apr 2025 19:37:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sealed

I did a first pass review of the public API -- I didn't look at the implementation yet.

modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 36:

> 34:  * as well as geometry of other shapes derived from the layout (selection, underline, etc.).
> 35:  * <p>
> 36:  * The information obtained via this object may change after the next layout cycle, which may come as a result

Since this is a view of the layout info for the current layout pass, do you think something like the following would be clearer:

"The information obtained via this object is stable until the next layout cycle. It may change after the next layout cycle, which ..."

modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 57:

> 55:      * @return the layout bounds
> 56:      */
> 57:     public abstract Rectangle2D getBounds(boolean includeLineSpacing);

Should this return a `Bounds` object?

modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 81:

> 79:      * @return the {@code TextLineInfo} object
> 80:      * @throws IndexOutOfBoundsException if the index is out of range
> 81:      *     {@code (index < 0 || index > getTextLineCount())}

Shouldn't that be ">= getTextLineCount()" ?

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 866:

> 864:     /**
> 865:      * The shape of the selection in coordinates
> 866:      * relative to the font base line.

Why did you remove the word "local"? The term "local coordinates" has meaning that is still valid here.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1119:

> 1117: 
> 1118:     /**
> 1119:      * Returns the shape for the strike-through in coordinates

"local coordinates"

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 2100:

> 2098:      * While there is no general guarantee that successive invocations of this method return the same instance,
> 2099:      * it is safe to either cache this object or call this method each time, since the information obtained from
> 2100:      * this lightweight object remains valid until the next layout cycle.

I'm trying to parse this to get a better idea of the model. If this really is a "view" into the current layout information for the text node, then the information returned by the getters in the TextLayout will change over time, right?

This is true whether you call the TextLayoutInfo once on a given text node and reuse it for the life of that text node or whether you call `Text::getLayoutInfo` every time you want to use it. I guess that's what you are trying to say. If so, is there a need to mention that there is no guarantee that it will return the same instance?

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 2104:

> 2102:      * The information obtained after the next layout cycle might be different as a result
> 2103:      * of actions such as resizing of the container, or modification of certain properties.
> 2104:      * For example updating the text or the font might change the layout, but a change of color would not.

This is a little ambiguous. It's the information that is obtained by the Layout info that is obtained by this`getLayout` method that might change, not the object returned by this method.

So I recommend either deleting this paragraph -- the LayoutInfo object describes the information it returns -- or else clarifying that this applies to the information obtained _from the LayoutInfo ojbect_.

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

PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2810058831
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070594753
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070640628
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070644149
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070424622
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070429860
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070589595
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070654997

From kcr at openjdk.org  Thu May  1 14:48:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 14:48:51 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <pZr0Bwyde1fKc2oItm8CzjsZ0Kwf3U2UEdQQVxuuM9w=.49066cf1-eb19-48f6-9d47-48673ad84ac4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <dWWdm42_W2BakDJ1psKgrHweCi4ORNejV2j5yu_H-dU=.21758034-390c-4709-aed2-a8f8749d3884@github.com>
 <xK-TpgHp9PGYGpwMiZ3Q2LPT4UJvv4_cXoxW7bomUmE=.a9363977-799d-4e33-9f86-63fecdbcb409@github.com>
 <pZr0Bwyde1fKc2oItm8CzjsZ0Kwf3U2UEdQQVxuuM9w=.49066cf1-eb19-48f6-9d47-48673ad84ac4@github.com>
Message-ID: <pUVIcqyUqkdl30nR3PIprzG48VL1L86stfnPg6qtuqw=.809a8bb8-4087-410a-a9fe-0fead84229ee@github.com>

On Thu, 1 May 2025 13:54:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I will check whether this is the case by trying out HelloFXCanvas after first setting that variable. If so, then the fix for [JDK-8340378](https://bugs.openjdk.org/browse/JDK-8340378) will be to set that env variable from HelloFXCanvas when running on Linux.

Running HelloFXCanvas with `GDK_BACKEND=x11` does prevent the crash. The SWT part of the app doesn't render well on my system, but that isn't a JavaFX issue.

I did a little more looking, and the SWT interop failure in Wayland mode was discovered and commented on back when we added the putenv in [JDK-8210411](https://bugs.openjdk.org/browse/JDK-8210411) in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8210411?focusedId=14230568&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14230568). We should have filed a follow-on bug back then, but at least we have [JDK-8340378](https://bugs.openjdk.org/browse/JDK-8340378) now.

Back to this PR: On my Ubuntu 24.04 VM it crashes without setting that env var and fails (hangs) when I do. Given the various problems, I recommend skipping all of the tests on Linux. The testing matrix will be a bit time consuming, and I'm not sure how important it really is.

The easiest way to skip on Linux might be in the build.gradle file when setting the SWT_TEST flag.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2844982951

From zelmidaoui at openjdk.org  Thu May  1 23:59:57 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 1 May 2025 23:59:57 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
Message-ID: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>

The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

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

Commit messages:
 - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

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

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

From kcr at openjdk.org  Thu May  1 19:01:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 May 2025 19:01:58 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v16]
In-Reply-To: <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ZIaXEMTbtzvZ8arXaFwUH5bp0-ubCsEvmx_NawNDuN4=.114e6bd5-1df2-4c49-805c-12a13512fb68@github.com>
 <koMHkh-j6oEyEkfkggbpNlwub3pGwXy7FIwZCA7KKRc=.0f9ae1b7-4e0c-4722-913b-e6fbffb6a379@github.com>
 <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
Message-ID: <N2S-o-9iupiathRvXMoS1n6SHw8AQucNpDz3gtjO8BE=.ebd1a056-d7f3-4978-8576-7267743944b5@github.com>

On Wed, 5 Feb 2025 21:21:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 91:
>> 
>>> 89:      * @return the immutable list of {@code Rectangle2D} objects
>>> 90:      */
>>> 91:     public abstract List<Rectangle2D> selectionShape(int start, int end, boolean includeLineSpacing);
>> 
>> I take that  `LayoutInfo::selectionShape` should match the existing API `TextFlow::rangeShape` for the same selection coordinates.
>>  
>> I wonder if you have tested this, with different insets. I take that with your current implementation, for `Rectangle2D` objects, it makes sense to have the insets of the TextFlow/Text node, but shapes don't include them.
>
> We've got https://bugs.openjdk.org/browse/JDK-8341438 and a possibility of a regression if we change the existing methods.
> 
> I would very much like to get your thoughts on this.

I also would like to hear thoughts about compatibility concerns around fixing [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).

If we are not going to fix it in the same release (JavaFX 25) as this Text LayoutInfo enhancement, I think we need a NOTE in the javadoc to clarify this difference.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2070663054

From mfox at openjdk.org  Fri May  2 02:31:49 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 2 May 2025 02:31:49 GMT
Subject: Integrated: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <AxTZm-pDrJrxHPa5FUbFyFMGdGhTwEkTMLeXZd3eVRY=.ceadac50-4cd7-4fae-8ad8-85577ef1abf0@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

This pull request has now been integrated.

Changeset: 096765a0
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/096765a0e51c5cf67d64b4b5f38ef3da3914db35
Stats:     9 lines in 1 file changed: 1 ins; 3 del; 5 mod

8353314: macOS: Inconsistent fullscreen behavior

Reviewed-by: angorya, kcr

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

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

From mfox at openjdk.org  Fri May  2 02:33:53 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 2 May 2025 02:33:53 GMT
Subject: Integrated: 8176813: Mac: Failure to exit full-screen programmatically
 in some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <mzJgHlcVPw3ryQb-FfmHS0Vrkhx7EmW7cO5Pi1qfnoo=.0acff45c-d65e-4b1f-82b4-bd4d12c017c0@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

This pull request has now been integrated.

Changeset: 498b7e4c
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/498b7e4cc56d91d6a0caf6a9a93691b0195e997b
Stats:     34 lines in 3 files changed: 25 ins; 4 del; 5 mod

8176813: Mac: Failure to exit full-screen programmatically in some cases

Reviewed-by: angorya, kcr

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

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

From mstrauss at openjdk.org  Fri May  2 10:32:42 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 10:32:42 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

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

  simplify header area picking

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/544d62eb..c602f504

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=70
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=69-70

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

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

From mstrauss at openjdk.org  Fri May  2 11:12:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 11:12:02 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <ENOoPj_MIn-mlafRNOZkFuLlLiBKu6m_nRI5vCi9BwQ=.789509c5-ba00-496c-93ed-ffe85f614ee2@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

Several people have commented on an artifact that can happen when the window is resized down below the minimum size of the header bar. In this case, the default window buttons will be drawn over the header bar content. Obviously, this doesn't look good.

I've experimented with a potential solution, where I added a new `HeaderBar.clipSystemInset` boolean property. If set to true, the content of the header bar is clipped to always exclude the side of the header bar that contains the window buttons (the red rectangle indicates the clipping rect):
<img src="https://github.com/user-attachments/assets/716f6f7d-b95e-4706-b331-cab467cd7d1b" width="300"/>

This works, but there are a few aspects to consider:

1. Clipping the header bar content requires me to put the content inside another container, and then clip this inner container. So the structure of the header bar looks like this: `HeaderBar` -> `ContentContainer` -> [children]. This is unusual for a layout container, which usually doesn't have an internal substructure.
2. The clipping approach works in trivial cases, but it doesn't work as easily in more complex cases. Consider an application like Chrome, where the header bar could conceivably be the entire region marked with a red rectangle: <img src="https://github.com/user-attachments/assets/70d7287e-0b9d-4a39-aea4-2ec65873797f" width="400"/>
The naive approach of clipping away the entire side of the header bar that contains the default window buttons wouldn't work here. We would probably need a more complex clipping shape that fits the design semantics of the application's header bar.
3. Then there's the question of whether we _really_ need this feature. It adds to the complexity of the implementation, and its value is debatable: an application should be designed so it doesn't need to rely on naive content clipping. It should define an appropriate minimum window size, and the window contents should gracefully adapt to small window sizes.

In fact, Chrome doesn't clip its header bar content, but scales it down to small icons and then prevents sizing the window below a reasonable minimum size. The same is true for Windows Explorer, Notepad, Spotify, and many other apps. The only application that comes to mind that clips its header bar content is IntelliJ.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2846959953

From mmack at openjdk.org  Fri May  2 11:21:15 2025
From: mmack at openjdk.org (Markus Mack)
Date: Fri, 2 May 2025 11:21:15 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <qmmZs0HGrrtSV4iJxzPbhPpz0MXMdfCtPMeiemIoIq0=.20914f3d-dd67-44ba-b19d-e5802f689170@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

Would it be feasible to ensure the minium window width is large enough by default, and allowing to turn this off when manual clipping is implemented instead?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2846974882

From duke at openjdk.org  Fri May  2 11:34:06 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Fri, 2 May 2025 11:34:06 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <IvtR0mYoQRSAz4hlDJh3Zgcko0ZvFfLWptjeTgAICn8=.316f13c7-e9a0-4db0-80fb-8c32ec8a4eb1@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

Apologies on my comment on the subject, I had not realised until after, that it was already discussed.

I would agree that "naive" clipping is probably more confusing than intuitive.

Anyway, note that even Windows Explorer doesn't do a great job.

E.g., depending on how fast you re-size the Window (in this case, with two tabs open), you can get this:

![image](https://github.com/user-attachments/assets/7b321d25-d14d-4d1b-be3e-b8e4fba3acb3)

...or this if you resize slower (no indication that two tabs are open -- but less "ugly"):

![image](https://github.com/user-attachments/assets/96f14be1-8a46-4256-aac3-d9e1d525a038)

I also prefer your suggestion that there should simply be a minimum window size.

But I can imagine a lot of people will want a menu in the top header bar; some maybe with too many items to be reasonably fit into a "minimum" size. 

Look at SceneBuilder (which has no min size), when resized, the menu items all get ellipsed -- not beautiful but at least it's something:

![image](https://github.com/user-attachments/assets/9c69ed8b-f39c-42de-85f8-3afef6be8d06)

Would this behave similarly in HeaderBar, or would it stay fullsize, and the window icons overlay it? (I am unable to test it at the moment)

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2846997152

From mstrauss at openjdk.org  Fri May  2 11:48:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 11:48:59 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <qmmZs0HGrrtSV4iJxzPbhPpz0MXMdfCtPMeiemIoIq0=.20914f3d-dd67-44ba-b19d-e5802f689170@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <qmmZs0HGrrtSV4iJxzPbhPpz0MXMdfCtPMeiemIoIq0=.20914f3d-dd67-44ba-b19d-e5802f689170@github.com>
Message-ID: <hBkZQEVhWrAftuq3aCkLCbDeBE0zZ4COSFcY6sCWbME=.4a510100-0963-4589-8bb7-4788f2060720@github.com>

On Fri, 2 May 2025 11:18:04 GMT, Markus Mack <mmack at openjdk.org> wrote:

> Would it be feasible to ensure the minium window width is large enough by default, and allowing to turn this off when manual clipping is implemented instead?

It's probably a bit hard with the API around `Stage.minWidth` and `Stage.minHeight`. Deriving a minimum size from the window content is probably easy (just measure the minimum size of the root node), but currently the stage doesn't reach into the scene graph to set its minimum size. The problem is also not exclusive to `HeaderBar`, as the window can currently be resized below the minimum size of the rest of the scene graph, too. Maybe we could have an option for `Stage` to always be large enough to accomodate the minimum scene graph size.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2847020509

From mstrauss at openjdk.org  Fri May  2 11:53:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 11:53:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <937oaHm8xgNtVgRFiRVr6t0BrhbrH1vm-_tc4XQeq5U=.2694bcb2-5f2d-4d5d-827a-09185aa743a4@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

> But I can imagine a lot of people will want a menu in the top header bar; some maybe with too many items to be reasonably fit into a "minimum" size.
> 
> Look at SceneBuilder (which has no min size), when resized, the menu items all get ellipsed -- not beautiful but at least it's something:
> 
> Would this behave similarly in HeaderBar, or would it stay fullsize, and the window icons overlay it? (I am unable to test it at the moment)

`MenuBar` seems to just stay full size. Maybe the best option would be to enhance `MenuBar` with an overflow area, where its menus will appear when there's not enough space to lay the menus out next to each other?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2847028192

From mfox at openjdk.org  Fri May  2 14:43:52 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 2 May 2025 14:43:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
Message-ID: <Z5Cwwy1UP5-okyFvFWI8_HfdCp6CaHpAcsjSHX-Dok8=.a0f44abe-66d9-4589-a69d-437dbf95b72a@github.com>

On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

New stage attribute tests are being written for PR #1789. I'll get some dual-monitor tests added and try to ensure they push the system a bit (like trying to trigger this bug).

Just realized that some of the existing tests expect that when a stage is taken out of fullscreen or maximized mode you will see one and only one update to the size and position properties. I'm not entirely sure that's a requirement we should be testing for.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2847375332

From angorya at openjdk.org  Fri May  2 14:47:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 14:47:53 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <Z5Cwwy1UP5-okyFvFWI8_HfdCp6CaHpAcsjSHX-Dok8=.a0f44abe-66d9-4589-a69d-437dbf95b72a@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>
 <Z5Cwwy1UP5-okyFvFWI8_HfdCp6CaHpAcsjSHX-Dok8=.a0f44abe-66d9-4589-a69d-437dbf95b72a@github.com>
Message-ID: <uUmEpOrrJkY5GaLM7_dDIFePaF1J4LZfb9BsZARLZMM=.68c1f883-e3bf-4699-bf3d-dd34453f3c8a@github.com>

On Fri, 2 May 2025 14:41:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I'm not entirely sure that's a requirement we should be testing for.

I agree.  We should test that it settles to the expected values eventually.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2847383534

From pavelturk2000 at gmail.com  Fri May  2 15:30:09 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Fri, 2 May 2025 18:30:09 +0300
Subject: CodeArea: What should SyntaxDecorator.createRichParagraph return for
 empty paragraphs?
Message-ID: <3f18cb2f-11fd-4432-8db7-2aed50163056@gmail.com>

Could anyone say what?createRichParagraph should return if the paragraph is empty (length = 0)?
For example, RichParagraph.builder().build(), or null, or ?

Best regards, Pavel

From andy.goryachev at oracle.com  Fri May  2 15:36:41 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 2 May 2025 15:36:41 +0000
Subject: CodeArea: What should SyntaxDecorator.createRichParagraph return
 for empty paragraphs?
In-Reply-To: <3f18cb2f-11fd-4432-8db7-2aed50163056@gmail.com>
References: <3f18cb2f-11fd-4432-8db7-2aed50163056@gmail.com>
Message-ID: <BYAPR10MB30131E8624F50715CB8FDA35E58D2@BYAPR10MB3013.namprd10.prod.outlook.com>

Definitely not null - the javadoc says nothing about null, perhaps it should be more explicit.  The paragraph may contain paragraph attributes, even when empty.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Friday, May 2, 2025 at 08:30
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: What should SyntaxDecorator.createRichParagraph return for empty paragraphs?
Could anyone say what createRichParagraph should return if the paragraph is empty (length = 0)?
For example, RichParagraph.builder().build(), or null, or ?

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250502/4de68258/attachment.htm>

From angorya at openjdk.org  Fri May  2 15:44:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 15:44:03 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread [v2]
In-Reply-To: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
Message-ID: <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>

> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
> 
> Also, ensure that the reverse process also happens in the FX application thread.

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 three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8355615.menubar
 - in fx thread
 - install

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1795/files
  - new: https://git.openjdk.org/jfx/pull/1795/files/d5bea119..a1552f63

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

  Stats: 84 lines in 8 files changed: 41 ins; 15 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1795.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1795/head:pull/1795

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

From angorya at openjdk.org  Fri May  2 16:54:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 16:54:56 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v23]
In-Reply-To: <pmpU0cyCiSXJtUDgByB-bNirUnaeT2vJD9Cf4NfBwLs=.e87e7c50-1fde-4976-bed7-5480ce56221d@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <COXsxBJaTLOpBjcyoBzPLmqRy6AN7n7uW_5J4vF0AVA=.647965aa-780a-4706-8248-a621fe1625b7@github.com>
 <jpI6FO_CrFjL40cSZPPBMri-hLmkIlO5ai8eEW2JGNA=.2ed09aa9-b3c9-4697-be9f-178b651c9922@github.com>
 <rexLOJ6STpt-XPKlKlta2CPdhCuSKAtXaJAbpxad-7E=.6ead5778-7c2a-40c8-91ab-171dd90da53f@github.com>
 <qnJu1fSsF8HLFFXKqz-cnXmdf5781GfbVSEFA7kW7Yk=.7abc99c7-7f9b-441a-b388-ae9852e66786@github.com>
 <pmpU0cyCiSXJtUDgByB-bNirUnaeT2vJD9Cf4NfBwLs=.e87e7c50-1fde-4976-bed7-5480ce56221d@github.com>
Message-ID: <jpPh4kvttpel5V9Lqg2zvh1GX5ZN2unbd6OCkw0Z2wY=.f4bad839-7eb2-4678-8ead-92f213c58b0d@github.com>

On Thu, 1 May 2025 15:39:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I understand the argument for `TextLineInfo`, I guess I'm looking more at `LayoutInfo` here. My question is whether it is really the best choice to sacrifice local consistency within a single class just to have it look more similar to equally inconsistently named methods in another class? Anyway, I just wanted to point this out, that's not a hill for me to die on.
>
> Is the "thickness" of the returned `Rectangle2D` significant? Typically this is a line, meaning that width would be 0 for horizontal text. I presume that the width can be > 0 and that it would do what you expect?

The widths are 0 with the PrismTextLayout.  I thought it'll be easier to package this information into a rectangle than simply return a bunch of values in an array and then try to describe the layout.  It also better in terms of extensibility (e.g. if we ever support vertical layouts).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071889865

From angorya at openjdk.org  Fri May  2 16:54:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 16:54:57 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
Message-ID: <byIqA_IUkd8ZNGnPFWtiPwx1ZIMC5SKqVHOpqfUUMLs=.fa0484d1-66c2-4989-9571-06a3190bafb7@github.com>

On Thu, 1 May 2025 15:41:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 866:
> 
>> 864:     /**
>> 865:      * The shape of the selection in coordinates
>> 866:      * relative to the font base line.
> 
> Why did you remove the word "local"? The term "local coordinates" has meaning that is still valid here.

reverted.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071892969

From angorya at openjdk.org  Fri May  2 17:00:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:00:01 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
Message-ID: <mal__UlcKUlV8D6uJ5sT-npZbmG7QdqHiFrXeiHbSLk=.3d22661f-9082-4bcd-9ca0-715876d821df@github.com>

On Thu, 1 May 2025 17:59:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 2100:
> 
>> 2098:      * While there is no general guarantee that successive invocations of this method return the same instance,
>> 2099:      * it is safe to either cache this object or call this method each time, since the information obtained from
>> 2100:      * this lightweight object remains valid until the next layout cycle.
> 
> I'm trying to parse this to get a better idea of the model. If this really is a "view" into the current layout information for the text node, then the information returned by the getters in the TextLayout will change over time, right?
> 
> This is true whether you call the TextLayoutInfo once on a given text node and reuse it for the life of that text node or whether you call `Text::getLayoutInfo` every time you want to use it. I guess that's what you are trying to say. If so, is there a need to mention that there is no guarantee that it will return the same instance?

good comment.  how does this sound:

Returns the object which provides a snapshot of the text layout geometry for this node.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071898115

From angorya at openjdk.org  Fri May  2 17:04:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:04:57 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
Message-ID: <J9KKXgLFm3HCLEKbgC_okPyZzp1dz7uDkYiPT3x-raA=.991e9fb5-be82-45ae-8b61-6961b359a652@github.com>

On Thu, 1 May 2025 18:04:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 36:
> 
>> 34:  * as well as geometry of other shapes derived from the layout (selection, underline, etc.).
>> 35:  * <p>
>> 36:  * The information obtained via this object may change after the next layout cycle, which may come as a result
> 
> Since this is a view of the layout info for the current layout pass, do you think something like the following would be clearer:
> 
> "The information obtained via this object is stable until the next layout cycle. It may change after the next layout cycle, which ..."

re-phrased to make it clearer:


 * Provides a snapshot of the text layout geometry in a {@code Text} or a {@code TextFlow} node,
 * such as break up of the text into lines, as well as other shapes derived from the layout
 * (selection, underline, etc.).
 * <p>
 * The information in this object is valid until the next layout cycle.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071904232

From angorya at openjdk.org  Fri May  2 17:10:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:10:03 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
Message-ID: <kETN9gaAdf88n6iM7MSghHgjDdUNm97Xli9wS4SsXKE=.9e511e76-ad46-49a8-8626-3f2c8f2d8a27@github.com>

On Thu, 1 May 2025 18:39:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 57:
> 
>> 55:      * @return the layout bounds
>> 56:      */
>> 57:     public abstract Rectangle2D getBounds(boolean includeLineSpacing);
> 
> Should this return a `Bounds` object?

No, this is strictly a 2D API, everything is expressed in lightweight Rectangle2D's.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071908720

From angorya at openjdk.org  Fri May  2 17:13:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:13:55 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <eZEEH_DKEpNwC8C0i7mfFYzkF1KGZ85QOQuAQqfTuT8=.1e2259a6-4337-441c-be9f-84c8b12e8974@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <eZEEH_DKEpNwC8C0i7mfFYzkF1KGZ85QOQuAQqfTuT8=.1e2259a6-4337-441c-be9f-84c8b12e8974@github.com>
Message-ID: <WhQvuUypjaORwfUOxPWAcNY3XKGTbaKTez0Mr-1p4aM=.10a86662-978c-453a-be42-dcdc81f5858f@github.com>

On Thu, 1 May 2025 18:54:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sealed
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 60:
> 
>> 58:      * @return the bounds of the caret segment
>> 59:      * @throws IndexOutOfBoundsException if the index is out of range
>> 60:      *     {@code (index < 0 || index > getSegmentCount())}
> 
> Shouldn't this be `>= getSegmentCount()`.

(hangs head in shame)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071913079

From angorya at openjdk.org  Fri May  2 17:20:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:20:57 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v16]
In-Reply-To: <N2S-o-9iupiathRvXMoS1n6SHw8AQucNpDz3gtjO8BE=.ebd1a056-d7f3-4978-8576-7267743944b5@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ZIaXEMTbtzvZ8arXaFwUH5bp0-ubCsEvmx_NawNDuN4=.114e6bd5-1df2-4c49-805c-12a13512fb68@github.com>
 <koMHkh-j6oEyEkfkggbpNlwub3pGwXy7FIwZCA7KKRc=.0f9ae1b7-4e0c-4722-913b-e6fbffb6a379@github.com>
 <eJL01Owju69Dxr1OkRyD-CljoXXGuPkzJvsDXxw1Ugc=.515015b0-493d-42b9-b459-6a8b1c235d7a@github.com>
 <N2S-o-9iupiathRvXMoS1n6SHw8AQucNpDz3gtjO8BE=.ebd1a056-d7f3-4978-8576-7267743944b5@github.com>
Message-ID: <nRPMAs1PoTcYQzqRMj9j442Dt6_6n_ECe3f0hyUgGmY=.e904a688-e815-4bc2-b8aa-d44de3899213@github.com>

On Thu, 1 May 2025 18:58:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> We've got https://bugs.openjdk.org/browse/JDK-8341438 and a possibility of a regression if we change the existing methods.
>> 
>> I would very much like to get your thoughts on this.
>
> I also would like to hear thoughts about compatibility concerns around fixing [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> If we are not going to fix it in the same release (JavaFX 25) as this Text LayoutInfo enhancement, I think we need a NOTE in the javadoc to clarify this difference.

Good point!  I think we should do the following in https://bugs.openjdk.org/browse/JDK-8341438 (after this PR gets integrated):

- deprecate the existing (buggy) methods, but keep them for compatibility
- add new methods, named `getX*Shape()`, with additional arguments where needed
- update javadoc for the existing methods, explaining the problem (possibly)

This will fix the issue and avoid breaking existing applications which applied workarounds.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071919907

From angorya at openjdk.org  Fri May  2 17:26:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:26:59 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
Message-ID: <xX-fJcERm3ce5fCWISH8Jm-l_TKREXVBmfLk-nTwyyA=.6b8159d7-4c48-40d3-a799-098d26a6e40c@github.com>

On Mon, 7 Apr 2025 19:37:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sealed

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 259:

> 257:      * @since 25
> 258:      */
> 259:     public final PathElement[] strikeThroughShape(int start, int end) {

Perhaps this method should be renamed to `getStrikeThroughShape()` to be consistent with the proposed evolution of the buggy methods in https://bugs.openjdk.org/browse/JDK-8341438

(same in `Text`)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2071925034

From angorya at openjdk.org  Fri May  2 17:42:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:42:45 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v26]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <u_1-Y2CrdRLuccSNdepq4h600wUmm6MEPGUOZ6d1kR8=.a81b83e0-e91a-4cd1-be38-be12207519c9@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

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

 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - sealed
 - indent
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - twice
 - tests
 - review comments
 - ... and 43 more: https://git.openjdk.org/jfx/compare/498b7e4c...982ef1f7

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=25
  Stats: 1520 lines in 13 files changed: 1461 ins; 18 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

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

From angorya at openjdk.org  Fri May  2 17:49:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 17:49:01 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v26]
In-Reply-To: <u_1-Y2CrdRLuccSNdepq4h600wUmm6MEPGUOZ6d1kR8=.a81b83e0-e91a-4cd1-be38-be12207519c9@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <u_1-Y2CrdRLuccSNdepq4h600wUmm6MEPGUOZ6d1kR8=.a81b83e0-e91a-4cd1-be38-be12207519c9@github.com>
Message-ID: <OX77hRu12PAedGNMHxVaJN90JjyakbXRmxj9I8XMWwI=.874e0cb0-c52b-4188-8312-c21f8d42840c@github.com>

On Fri, 2 May 2025 17:42:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - sealed
>  - indent
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - twice
>  - tests
>  - review comments
>  - ... and 43 more: https://git.openjdk.org/jfx/compare/498b7e4c...982ef1f7

I'll update the CSR once the javadoc settles.

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

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2847770006

From mmack at openjdk.org  Fri May  2 18:28:10 2025
From: mmack at openjdk.org (Markus Mack)
Date: Fri, 2 May 2025 18:28:10 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <hBkZQEVhWrAftuq3aCkLCbDeBE0zZ4COSFcY6sCWbME=.4a510100-0963-4589-8bb7-4788f2060720@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <qmmZs0HGrrtSV4iJxzPbhPpz0MXMdfCtPMeiemIoIq0=.20914f3d-dd67-44ba-b19d-e5802f689170@github.com>
 <hBkZQEVhWrAftuq3aCkLCbDeBE0zZ4COSFcY6sCWbME=.4a510100-0963-4589-8bb7-4788f2060720@github.com>
Message-ID: <-84I5FSZU__3_vlEYvccmHW_3vajJ5bJsr46g7eO-l0=.b92de797-c809-40b4-b97b-764483a68111@github.com>

On Fri, 2 May 2025 11:46:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> > Would it be feasible to ensure the minium window width is large enough by default, and allowing to turn this off when manual clipping is implemented instead?
> 
> It's probably a bit hard with the API around `Stage.minWidth` and `Stage.minHeight`. Deriving a minimum size from the window content is probably easy (just measure the minimum size of the root node), but currently the stage doesn't reach into the scene graph to set its minimum size. The problem is also not exclusive to `HeaderBar`, as the window can currently be resized below the minimum size of the rest of the scene graph, too. Maybe we could have an option for `Stage` to always be large enough to accomodate the minimum scene graph size.

Ok, that would need to be done elsewhere then.
I'd be fine with either adding documentation that this window size issue needs to be handled somehow by the app, or going with the automatic content clipping with the `HeaderBar.clipSystemInset` flag as proposed, which can be turned off when the more complex cases arise.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2847836730

From kcr at openjdk.org  Fri May  2 18:48:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 May 2025 18:48:04 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <g5dz3qyuvnkQPwlmWiFeP-IFyryk-qkTpaGEJlykz2k=.7a0536ac-3953-471e-983a-37675c132ee2@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

The API looks good to me. I want to do a second pass over the javadocs once I have time to try a few things, but I doubt I'll request any significant changes.

Go ahead and create the CSR when you are ready.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2847871327

From angorya at openjdk.org  Fri May  2 19:16:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 19:16:49 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <fNPY1jBwkMiRKJuWukOfaoPVyCPcAiWE6o-6unekR20=.76f8908d-aa34-4d23-89ed-643d277c3211@github.com>

On Thu, 1 May 2025 22:08:46 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

Looks good.  Thanks for the test, nice idea with the "double-parameterized" case.

1 reviewer should be sufficient.  Please wait 24 hrs before integrating.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1801#pullrequestreview-2812733235

From mstrauss at openjdk.org  Fri May  2 19:28:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 19:28:49 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <O1cFU7TWaibK0_F-ykr-rhwNfgefpBCDckLGMP4Yxxw=.e4ecfd29-7430-447a-bc63-d6c13e2ff21f@github.com>

On Thu, 1 May 2025 22:08:46 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

I don't think that styling details of the Modena theme should be unit-tested in `TextInputControlTest`. First of all, this has nothing to do with the `TextInputControl` implementation. Second, it seems a bit pointless to me to unit-test individual styling aspects of one particular CSS theme, it's not what unit tests are meant to do.

I'm interested in a second opinion on whether we should do this kind of testing, and what in particular it should accomplish.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2847938322
PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2847939449

From angorya at openjdk.org  Fri May  2 20:40:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 20:40:50 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <O1cFU7TWaibK0_F-ykr-rhwNfgefpBCDckLGMP4Yxxw=.e4ecfd29-7430-447a-bc63-d6c13e2ff21f@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <O1cFU7TWaibK0_F-ykr-rhwNfgefpBCDckLGMP4Yxxw=.e4ecfd29-7430-447a-bc63-d6c13e2ff21f@github.com>
Message-ID: <6r_MrR--2gi_8Lbli2q3FACcX37XA5Ih24Qgtkxygeg=.28eb9b8d-dbd9-466f-a3ed-00f827047e3d@github.com>

On Fri, 2 May 2025 19:24:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I'm interested in a second opinion on whether we should do this kind of testing, and what in particular it should accomplish.

We already have `fontSetFromCSS()` test there, so I am not against adding a test in this file.

You do bring a good point though, which is whether we should do in respect to CSS.  Perhaps we should add a set of tests that verify that CSS properties are loaded from 
- inline style
- scene stylesheet
- user agent stylesheet

(unless we have these tests already)

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848079363

From mstrauss at openjdk.org  Fri May  2 21:11:53 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 21:11:53 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <6r_MrR--2gi_8Lbli2q3FACcX37XA5Ih24Qgtkxygeg=.28eb9b8d-dbd9-466f-a3ed-00f827047e3d@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <O1cFU7TWaibK0_F-ykr-rhwNfgefpBCDckLGMP4Yxxw=.e4ecfd29-7430-447a-bc63-d6c13e2ff21f@github.com>
 <6r_MrR--2gi_8Lbli2q3FACcX37XA5Ih24Qgtkxygeg=.28eb9b8d-dbd9-466f-a3ed-00f827047e3d@github.com>
Message-ID: <pRKNU9yXuNUipyuGnV9sGZFUv-PyoumeSZZFwLH2-TQ=.9f75ed47-c7dd-4d42-bcd3-185843c37b26@github.com>

On Fri, 2 May 2025 20:38:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> We already have `fontSetFromCSS()` test there, so I am not against adding a test in this file.

That's not my point. `fontSetFromCSS` tests whether a font can be set via CSS, which concerns the implementation of `TextInputControl`. In contrast to that, the test in this PR doesn't test any aspect of `TextInputControl` at all. It tests the Modena theme, which doesn't belong here.
 
> You do bring a good point though, which is whether we should do in respect to CSS. Perhaps we should add a set of tests that verify that CSS properties are loaded from
> 
> * inline style
> * scene stylesheet
> * user agent stylesheet
> 
> (unless we have these tests already)

This seems a bit too much, since we already have tests for the CSS infrastructure that applies values to styleable properties. I don't think we need to repeat that for each individual property, at least not manually.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848124960

From angorya at openjdk.org  Fri May  2 21:26:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 21:26:51 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <pRKNU9yXuNUipyuGnV9sGZFUv-PyoumeSZZFwLH2-TQ=.9f75ed47-c7dd-4d42-bcd3-185843c37b26@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <O1cFU7TWaibK0_F-ykr-rhwNfgefpBCDckLGMP4Yxxw=.e4ecfd29-7430-447a-bc63-d6c13e2ff21f@github.com>
 <6r_MrR--2gi_8Lbli2q3FACcX37XA5Ih24Qgtkxygeg=.28eb9b8d-dbd9-466f-a3ed-00f827047e3d@github.com>
 <pRKNU9yXuNUipyuGnV9sGZFUv-PyoumeSZZFwLH2-TQ=.9f75ed47-c7dd-4d42-bcd3-185843c37b26@github.com>
Message-ID: <fH08W_NvIH0p2iv1k9j8UU5kyQkWZRCTDfJrnl2fb6Q=.8e31e833-faf5-4d5c-b112-a4d8a7e4fb92@github.com>

On Fri, 2 May 2025 21:09:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I don't think we need to repeat that for each individual property, at least not manually.

Maybe not manually, but a reflection-based test that verifies each `Styleable` property (and also verify that these properties are listed in the cssref.html somehow).

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848145889

From angorya at openjdk.org  Fri May  2 21:45:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 21:45:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <UreUbbVGeLql5D-N6D09-8_O-w6sFUJCza2QrGSmco8=.7e34cb01-4818-43f7-967c-f47e2dcb8b0a@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
 <UreUbbVGeLql5D-N6D09-8_O-w6sFUJCza2QrGSmco8=.7e34cb01-4818-43f7-967c-f47e2dcb8b0a@github.com>
Message-ID: <C0TkGlkuwJoGVpMzBzgjfLKdcrjiJ4u7_D5sI4gpYBg=.b6af5768-1977-47a0-b624-a70b983d1729@github.com>

On Mon, 14 Apr 2025 14:35:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 31:
>> 
>>> 29: import java.util.function.Predicate;
>>> 30: 
>>> 31: public final class TokenStream {
>> 
>> I think the naming of the methods in this class leaves something to be desired.
>> 
>> - `Token consume()` **OK**
>> - `Token consume(Predicate)` -> `consumeIf` or `consumeIfMatches`
>>     Makes it clearer, as `consume` seems to imply something is always consumed (ie. it still skips one token if the predicate didn't match returning `null`).
>> - `Token peek()` **OK**
>> - `reconsume` -> `unconsume`, `undoConsume`, `undo`, `previous`, `resetToPrevious`, `decrementIndex`
>>     Nothing is consumed which reconsume seems to imply, instead it moves the index back one place so the next call to `consume` may indeed reconsume a token; reconsume as-is would do nothing (and if it returned anything it would be same the as `current`.
>> - `boolean peekMany(Predicate...)` -> `matches`
>>     It doesn't work like `peek`.  `peekMany` would imply it returns a `List<Token>`; it also doesn't convey that it returns a `boolean`.
>> - `reset(int)` -> `setIndex`
>>     This seems to be similar to what say `InputStream` provides, but `InputStream` hides the `index` parameter so you can't set it to some arbitrary value (like skipping ahead).  If you want to mimic this pattern, I'd suggest removing the parameter and providing a `mark` method (or make it non-public).
>
> I renamed `consume(Predicate)` to `consumeIf(Predicate)`, and `peekMany(Predicate...)` to `matches(Predicate...)`.
> 
> `index()` and `reset()` don't need to be public, so I've removed that (also I don't want to mimic the problematic mark/reset pattern of `InputStream`).
> 
> `reconsume` is [CSS lingo](https://www.w3.org/TR/css-syntax-3/#tokenizer-definitions), I'm keeping that as-is.

`reconsume` -> `resetToPrevious` + mention "reconsume" in javadoc?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2072177991

From mstrauss at openjdk.org  Fri May  2 21:55:52 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 May 2025 21:55:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <C0TkGlkuwJoGVpMzBzgjfLKdcrjiJ4u7_D5sI4gpYBg=.b6af5768-1977-47a0-b624-a70b983d1729@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
 <UreUbbVGeLql5D-N6D09-8_O-w6sFUJCza2QrGSmco8=.7e34cb01-4818-43f7-967c-f47e2dcb8b0a@github.com>
 <C0TkGlkuwJoGVpMzBzgjfLKdcrjiJ4u7_D5sI4gpYBg=.b6af5768-1977-47a0-b624-a70b983d1729@github.com>
Message-ID: <OouRsQQ_Tf4JEfeSdoGTLSCcM3BZfJ_6LwEl1wXtka0=.21dcf698-3ded-4a79-b242-09273e3b133b@github.com>

On Fri, 2 May 2025 21:43:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I renamed `consume(Predicate)` to `consumeIf(Predicate)`, and `peekMany(Predicate...)` to `matches(Predicate...)`.
>> 
>> `index()` and `reset()` don't need to be public, so I've removed that (also I don't want to mimic the problematic mark/reset pattern of `InputStream`).
>> 
>> `reconsume` is [CSS lingo](https://www.w3.org/TR/css-syntax-3/#tokenizer-definitions), I'm keeping that as-is.
>
> `reconsume` -> `resetToPrevious` + mention "reconsume" in javadoc?

I don't want to die on the `reconsume` hill here, but I think there is some value in being able to read through the W3C specification of the CSS algorithms, and find similar terminology in our implementation. Makes it a bit easier to correlate specification and implementation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2072184243

From angorya at openjdk.org  Fri May  2 21:59:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 21:59:50 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <OouRsQQ_Tf4JEfeSdoGTLSCcM3BZfJ_6LwEl1wXtka0=.21dcf698-3ded-4a79-b242-09273e3b133b@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
 <UreUbbVGeLql5D-N6D09-8_O-w6sFUJCza2QrGSmco8=.7e34cb01-4818-43f7-967c-f47e2dcb8b0a@github.com>
 <C0TkGlkuwJoGVpMzBzgjfLKdcrjiJ4u7_D5sI4gpYBg=.b6af5768-1977-47a0-b624-a70b983d1729@github.com>
 <OouRsQQ_Tf4JEfeSdoGTLSCcM3BZfJ_6LwEl1wXtka0=.21dcf698-3ded-4a79-b242-09273e3b133b@github.com>
Message-ID: <UxR7xDT9LfscGYbyXF70RbQXj0ZKhTjrY7lHAUlxRqc=.e7339efd-43b1-4cfe-a054-83fba2271cf0@github.com>

On Fri, 2 May 2025 21:53:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> `reconsume` -> `resetToPrevious` + mention "reconsume" in javadoc?
>
> I don't want to die on the `reconsume` hill here, but I think there is some value in being able to read through the W3C specification of the CSS algorithms, and find similar terminology in our implementation. Makes it a bit easier to correlate specification and implementation.

I think there is value in clarity, especially if we are not implementing 100% of the "spec".  I agree with John this name is suboptimal.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2072189333

From angorya at openjdk.org  Fri May  2 22:38:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 May 2025 22:38:51 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
Message-ID: <Th1oOlzh9i6tpRu0CnlU8Ps5yHaMTyc3qUOAh3CswZY=.92d0611c-f094-467f-8222-3223c0f5ef18@github.com>

On Mon, 28 Apr 2025 07:38:37 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 28 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - reorder fields
>  - remove ReadOnlyBooleanWrapper
>  - Scene preferences only actively observe platform preferences when the scene is showing
>  - formatting
>  - typo
>  - use equality instead of identity
>  - rename TokenStream methods
>  - improved implementation of NullCoalescingPropertyBase
>  - small refactor
>  - ... and 18 more: https://git.openjdk.org/jfx/compare/3fdd2138...32abb8a3

Would it be possible to expand the examples in the .md file?  For example, an example that uses operator(s)?  

Another question: is there any special prioritization given to media queries relative to other rules?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2848225925

From duke at openjdk.org  Fri May  2 22:42:00 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Fri, 2 May 2025 22:42:00 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <U6f_MOvAt43-d7ejm7CD_pxXEeSeYNJVbQql9FW8bVU=.e853e9fe-2c9c-45c4-86fe-f7a9c09c4088@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

I imagine most people will want HeaderBar's leading node to be an app icon with the usual left-click content menu behaviour (i.e., at least restore, minimise, close), much like it is today.

Today, you can add a bunch of icons to a stage with stage.getIcons().addAll(myLogoList)), and the window's header will contain a suitable icon; never too big, never too small. The developer doesn't worry about it.

I really feel adding an equivalent app icon to the HeaderBar should provided out-of-the-box, using the same logic. E.g., let HeaderBar choose the most suitable, and choose the correct size for the platform. Otherwise, the developer needs to think about it too much again.

A lot of this logic seems to be buried in WindowStage in terms of picking what icons to display in the title bar and when iconified, etc.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2848228251

From zelmidaoui at openjdk.org  Fri May  2 23:29:51 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 2 May 2025 23:29:51 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <J8RlYJIc9uzXQs2NOAD1aqSQC4vFj9_StvuYbQshaG8=.5c78883a-3e4d-4cc2-8ab4-687cf8c8f5f4@github.com>

On Thu, 1 May 2025 22:08:46 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

I can put the test in the `StylesheetTest` class, which might be more appropriate for this case. what do you think ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848271230

From mstrauss at openjdk.org  Sat May  3 07:25:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 May 2025 07:25:55 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <J8RlYJIc9uzXQs2NOAD1aqSQC4vFj9_StvuYbQshaG8=.5c78883a-3e4d-4cc2-8ab4-687cf8c8f5f4@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <J8RlYJIc9uzXQs2NOAD1aqSQC4vFj9_StvuYbQshaG8=.5c78883a-3e4d-4cc2-8ab4-687cf8c8f5f4@github.com>
Message-ID: <5YfIzTbfETrOUOrE1ox8JgUOZTOahoDmvmYumVmx-KY=.49738026-ac8c-4134-ba0a-09747cff9254@github.com>

On Fri, 2 May 2025 23:27:38 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> I can put the test in the `StylesheetTest` class, which might be more appropriate for this case. what do you think ?

No, because you're not testing the `Stylesheet` class either. What you are doing is testing the Modena theme, for which we have no appropriate testing methodology in JavaFX. I would rather just remove the test entirely, because this new test is going to be another person's future work. It's also more of a change tracker than a unit test, as a style is not a meaningful unit of code. If we want to start testing stylesheets, we should first have a discussion on goals and methodology.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848482322

From mstrauss at openjdk.org  Sat May  3 08:38:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 May 2025 08:38:01 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <U6f_MOvAt43-d7ejm7CD_pxXEeSeYNJVbQql9FW8bVU=.e853e9fe-2c9c-45c4-86fe-f7a9c09c4088@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <U6f_MOvAt43-d7ejm7CD_pxXEeSeYNJVbQql9FW8bVU=.e853e9fe-2c9c-45c4-86fe-f7a9c09c4088@github.com>
Message-ID: <yIOxTSbxfWYlDGzvtvgBK3vWvhsALvKCM4ZlU0p7Vlk=.2b31ec6b-9647-4182-a376-d93133a3d44c@github.com>

On Fri, 2 May 2025 22:38:51 GMT, Cormac Redmond <duke at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify header area picking
>
> I imagine most people will want HeaderBar's leading node to be an app icon with the usual left-click context menu behaviour (i.e., at least restore, minimise, close), much like it is for DECORATED today.
> 
> Today, you can add a bunch of icons to a stage with stage.getIcons().addAll(myLogoList)), and the window's header will contain a suitable icon; never too big, never too small. The developer doesn't worry about it.
> 
> I really feel a utility to add an equivalent app icon to the HeaderBar, should be provided out-of-the-box, using the same logic. E.g., let HeaderBar choose the most suitable icon, and choose the correct size for the platform, and any padding, etc. Otherwise, the developer needs to think about it too much.
> 
> A lot of this logic used by DECORATED, seems to be buried in WindowStage in terms of picking what icons to display in the title bar, etc.

@credmond
I think we run the risk of overloading `HeaderBar` with too many narrow features. Here are a few observations:
1. Modern applications tend to not use program icons. Windows Explorer, Calendar, Weather, Settings, and also Spotify or Chrome don't use it. Program icons have become more of a Win32-era relict, and it's mostly applications that use system-decorated windows that have it.
2. Program icons are really only a thing on Windows. It doesn't seem to make much sense to have a Windows-only API on a multi-platform toolkit. It certainly doesn't work with macOS, as we have the traffic lights in front of the leading node of the `HeaderBar`.
3. It's very easy to create a program icon with standard JavaFX controls. Since its size will never change, you can just use a static image with an `ImageView` and a `ContextMenu`. JavaFX already supports multi-resolution images out of the box (with the `@Nx` file name convention).
4. If you choose to have a program icon, you most likely want it to align nicely with the rest of your custom header bar. Even in apps that have a program icon, it's not a one-size-fits-all (for example, the IntelliJ program icon looks significantly different than a standard system-decorated program icon). Once you start to customize the program icon, you're really better off just using standard JavaFX controls to do the job.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2848521497

From mstrauss at openjdk.org  Sat May  3 08:56:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 May 2025 08:56:07 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>

> 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 30 commits:

 - Merge branch 'master' into feature/media-queries
 - cssref doc
 - Merge branch 'master' into feature/media-queries
 - reorder fields
 - remove ReadOnlyBooleanWrapper
 - Scene preferences only actively observe platform preferences when the scene is showing
 - formatting
 - typo
 - use equality instead of identity
 - rename TokenStream methods
 - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=20
  Stats: 5139 lines in 41 files changed: 3987 ins; 1050 del; 102 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  Sat May  3 08:56:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 May 2025 08:56:07 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <Th1oOlzh9i6tpRu0CnlU8Ps5yHaMTyc3qUOAh3CswZY=.92d0611c-f094-467f-8222-3223c0f5ef18@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <Th1oOlzh9i6tpRu0CnlU8Ps5yHaMTyc3qUOAh3CswZY=.92d0611c-f094-467f-8222-3223c0f5ef18@github.com>
Message-ID: <XOLBWHYODg_1owp6QAMTy-ALlsySSJAm_-7pEdv3k80=.977fc2d6-5b1f-4f25-95fc-3e47c0fbe126@github.com>

On Fri, 2 May 2025 22:36:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Another question: is there any special prioritization given to media queries relative to other rules?

No, a media query just either matches, or it doesn't. If it matches, the rule enclosed by the media query is treated like any other rule; if it doesn't match, the rule doesn't apply.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2848527090

From duke at openjdk.org  Sat May  3 10:48:01 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Sat, 3 May 2025 10:48:01 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <yIOxTSbxfWYlDGzvtvgBK3vWvhsALvKCM4ZlU0p7Vlk=.2b31ec6b-9647-4182-a376-d93133a3d44c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <U6f_MOvAt43-d7ejm7CD_pxXEeSeYNJVbQql9FW8bVU=.e853e9fe-2c9c-45c4-86fe-f7a9c09c4088@github.com>
 <yIOxTSbxfWYlDGzvtvgBK3vWvhsALvKCM4ZlU0p7Vlk=.2b31ec6b-9647-4182-a376-d93133a3d44c@github.com>
Message-ID: <9rSsPyV1kgDEgCZpH4dgD4HcVvpVkEZgsOP5fpySAYQ=.a0b8a631-bf19-4f87-93f5-bd559ff6ba98@github.com>

On Sat, 3 May 2025 08:35:15 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I imagine most people will want HeaderBar's leading node to be an app icon with the usual left-click context menu behaviour (i.e., at least restore, minimise, close), much like it is for DECORATED today.
>> 
>> Today, you can add a bunch of icons to a stage with stage.getIcons().addAll(myLogoList)), and the window's header will contain a suitable icon; never too big, never too small. The developer doesn't worry about it.
>> 
>> I really feel a utility to add an equivalent app icon to the HeaderBar, should be provided out-of-the-box, using the same logic. E.g., let HeaderBar choose the most suitable icon, and choose the correct size for the platform, and any padding, etc. Otherwise, the developer needs to think about it too much.
>> 
>> A lot of this logic used by DECORATED, seems to be buried in WindowStage in terms of picking what icons to display in the title bar, etc.
>
> @credmond
> I think we run the risk of overloading `HeaderBar` with too many narrow features. Here are a few observations:
> 1. Modern applications tend to not use program icons. Windows Explorer, Calendar, Weather, Settings, and also Spotify or Chrome don't use it. Program icons have become more of a Win32-era relict, and it's mostly applications that use system-decorated windows that have it.
> 2. Program icons are really only a thing on Windows. It doesn't seem to make much sense to have a Windows-only API on a multi-platform toolkit. It certainly doesn't work with macOS, as we have the traffic lights in front of the leading node of the `HeaderBar`.
> 3. It's very easy to create a program icon with standard JavaFX controls. Since its size will never change, you can just use a static image with an `ImageView` and a `ContextMenu`. JavaFX already supports multi-resolution images out of the box (with the `@Nx` file name convention).
> 4. If you choose to have a program icon, you most likely want it to align nicely with the rest of your custom header bar. Even in apps that have a program icon, it's not a one-size-fits-all (for example, the IntelliJ program icon looks significantly different than a standard system-decorated program icon). Once you start to customize the program icon, you're really better off just using standard JavaFX controls to do the job.

Thanks for the detailed reply @mstr2. I can't really argue with any of your points, I also agree.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2848565539

From mhanl at openjdk.org  Sat May  3 15:05:49 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 3 May 2025 15:05:49 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <-EG9kAuynLGItMVEjia6XSwnwfjvb9Q8CecAtJxw25c=.127b1a2e-7983-4390-86db-6231d35989c6@github.com>

On Thu, 1 May 2025 22:08:46 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

I think the tests are still nice, but we might want to have a separate test class, something like `ModenaStylesheetTest`? 
I see your point that we are testing the modena stylesheet only here, but that itself is fine in my opinion.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2848663962

From pavelturk2000 at gmail.com  Sat May  3 17:07:00 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Sat, 3 May 2025 20:07:00 +0300
Subject: CodeArea: -fx-background-color doesn't work.
Message-ID: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>

For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.

Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
they?have?-rtfx-background-color.

public?class?JfxCodeArea?extends?Application?{

 ????@Override
 ????public?void?start(Stage?primaryStage)?throws?Exception?{
 ????????String?text?=?"""
 ??????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
 ??????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
 ??????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
 ??????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
 ??????????????????????""";

 ????????String?css?=?"""
 ????????????.test?{
 ????????????????-fx-font-weight:?bold;
 ????????????????-fx-fill:?red;
 ????????????????-fx-background-color:?green;
 ????????????}

 ????????""";
 ????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

 ????????CodeArea?codeArea?=?new?CodeArea();
 ????????codeArea.getStylesheets().add(data);

 ????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
 ????????????@Override
 ????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
 ????????????????var?builder?=?RichParagraph.builder();
 ????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
 ????????????????return?builder.build();
 ????????????}

 ????????????@Override
 ????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{

 ????????????}
 ????????});

 ????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
 ????????var?button?=?new?Button("Go!");
 ????????button.setOnAction(e?->?codeArea.setText(text));
 ????????VBox?root?=?new?VBox(codeArea,?button);
 ????????Scene?scene?=?new?Scene(root,?600,?200);
 ????????primaryStage.setScene(scene);
 ????????primaryStage.show();

 ????}

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

Best?regards,?Pavel

From duke at openjdk.org  Sat May  3 22:24:00 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Sat, 3 May 2025 22:24:00 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <Rj3dUWCh1j4NOUhaFatYn0lUPaN7jwkgW3lcw9fIX9g=.0a1eed4d-fef4-4ed2-a78b-2cb06c2dcd41@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

I was testing the HeaderBar, and noticed the styles of the windows buttons were sometimes not applied, or were getting stuck in a particular state (i.e., hover state). I thought I tracked this down to a benign issue where my app was applying duplicate stylesheets, in quick succession (i.e., twice) -- it should not matter usually, at all, but for some reason affected the window decoration icons in particular.

I fixed that edge-case issue. However, I then quickly noticed the styling will stop being applied after using a common controlsfx notification popup. It can be very easily reproduced:


package com.certak.kafkio.gui;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HeaderBar;
import javafx.stage.Stage;
import javafx.stage.StageStyle;
import org.controlsfx.control.Notifications;

import java.time.LocalDateTime;

public class WindowDecorationsStylesGoMissing extends Application {

    @Override
    public void start(Stage primaryStage) {
        primaryStage.initStyle(StageStyle.EXTENDED);
        BorderPane borderPane = new BorderPane();
        borderPane.setTop(new HeaderBar());

        Button click = new Button("Click");
        click.setOnAction(event -> {
            notify("Clicked at: " + LocalDateTime.now(), primaryStage);
        });
        borderPane.setCenter(click);

        Scene scene = new Scene(borderPane, 400, 300);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    public void notify(String message, Stage mainWindow) {
        Notifications.create()
                .text(message)
                .owner(mainWindow)
                .show();
    }

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


Run this, click the button and hover over the window icons, and see that no styling is applied anymore. I have not dived into this yet to understand _why_, but I know from memory that controlsfx does some re-arranging of nodes in scene usually.

Either way, the styling of HeaderBar seems quite unreliable/brittle given the various ways it can seemingly break. I don't know why, or what makes it different. But the other styles in my app appear unaffected by application bugs and/or quirks of controlsfx.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2848834102

From duke at openjdk.org  Sat May  3 23:18:01 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Sat, 3 May 2025 23:18:01 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <v8wKnGGsJJBJ_4xe8ZupDNnLU-GY2_VasV2X93zGySM=.350a2846-9271-4fdc-b797-a2c152b02125@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

Actually, it can easily be reproduced with plain Java + JavaFX; no libraries.

Turns out, the issue is down to doing:

` primaryStage.getScene().getStylesheets().addFirst(stylesheetUrl);
`


package com.certak.kafkio.gui;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HeaderBar;
import javafx.stage.Stage;
import javafx.stage.StageStyle;

import java.util.Objects;

public class WindowDecorationsStylesGoMissing extends Application {

    @Override
    public void start(Stage primaryStage) {
        primaryStage.initStyle(StageStyle.EXTENDED);
        BorderPane borderPane = new BorderPane();
        borderPane.setTop(new HeaderBar());

        Button click = new Button("Click");
        click.setOnAction(event -> {
            String stylesheetUrl = Objects.requireNonNull(AppSplashScreen.class.getResource("splash.css")).toExternalForm();
            primaryStage.getScene().getStylesheets().addFirst(stylesheetUrl);
        });
        borderPane.setCenter(click);

        Scene scene = new Scene(borderPane, 400, 300);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

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

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2848853006

From zjx001202 at gmail.com  Sun May  4 08:18:24 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 4 May 2025 16:18:24 +0800
Subject: Add more useful APIs to javafx.scene.text.Font
Message-ID: <CAJL5A3maeoaJmrbEd+54-RZ-B70Z3ZBrxnEodSzE6MW0iCWH=A@mail.gmail.com>

Hi,

We have noticed that JavaFX's strategy for selecting default fonts can
sometimes be quite odd,
and at times it doesn't properly follow the fontconfig configuration. As a
result,
we frequently receive feedback from Linux users reporting that all Chinese
characters appear as garbled text.
This[1] is one piece of the feedback that contains useful information.

We are not sure whether these problems can be solved. However, we've
noticed that unlike AWT,
javafx.scene.text.Font API lacks most useful methods. For example, it does
not provide
canDisplay/canDisplayUpTo methods, making it impossible to determine
whether
a font can render a given text. I found that CharToGlyphMapper actually
contains
the corresponding method, but it is not exposed through the Font API.

So is it possible to add more useful API methods to Font, like AWT does?
This will be of great help to us.

Glavo

[1]: https://github.com/HMCL-dev/HMCL/issues/3104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250504/070d65a0/attachment.htm>

From duke at openjdk.org  Sun May  4 10:23:03 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Sun, 4 May 2025 10:23:03 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
Message-ID: <c63EPlN4XFnW4CiMMV4_Rh2B3HyfvH16vfZ6St2MrxE=.a5e53449-c3dc-4c29-a4e9-465ba086e031@github.com>

On Fri, 2 May 2025 10:32:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify header area picking

An even more concise example. Create c:\empty.css and run this, then hover over the window icons and note no style is applied (or is partially applied):


 @Override
    public void start(Stage primaryStage) {
        BorderPane borderPane = new BorderPane();
        borderPane.setTop(new HeaderBar());
        Scene scene = new Scene(borderPane, 400, 300);
        primaryStage.setScene(scene);
        primaryStage.initStyle(StageStyle.EXTENDED);
        primaryStage.show();
        // Calling this once shown, breaks the window decoration (minimise/restore/close) CSS
        scene.getStylesheets().add(Paths.get("C:\\empty.css").toUri().toString());
        
        // Even reproducible on a non-existing file
        // scene.getStylesheets().add(Paths.get("C:\\i_dont_even_need_to_exist.css").toUri().toString());
    }

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2849128835

From tsayao at openjdk.org  Sun May  4 13:00:53 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 4 May 2025 13:00:53 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v13]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <OwxEIRlcUXmVjc6ZDLyopWPfb4-LxvazsFQK_y3AkKk=.d5c1a767-abfd-4886-a5aa-ec0a80051562@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Improve TestStage
  - Notify maximize/fullscreen before show on native side

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/d25ea134..10aff17e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=11-12

  Stats: 680 lines in 4 files changed: 348 ins; 211 del; 121 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Sun May  4 13:46:35 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 4 May 2025 13:46:35 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v14]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <nUAKIK8jXvUTA0Yq8q68q2ryhGX_foRTE_2nTrIpfAI=.dd09fd15-39a7-48dd-8e1f-0d5ed26040de@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  TestStage

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/10aff17e..a0eb021a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=12-13

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

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

From mstrauss at openjdk.org  Sun May  4 14:33:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 May 2025 14:33:45 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v72]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <-f5RiHk279EnQLi7rR7DFT9Z1jFUiicX9YKGR9MxN3k=.a35538e6-80e8-4c8a-af54-ff4bf8a42373@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:

 - reapply overlay CSS
 - Merge branch 'master' into feature/extended-window
 - simplify header area picking
 - Fix top resize border on Windows
 - Merge branch 'master' into feature/extended-window
 - doc change
 - add HeaderDragType
 - add MenuBar to stage tester
 - documentation
 - review comments
 - ... and 83 more: https://git.openjdk.org/jfx/compare/498b7e4c...18ab411d

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=71
  Stats: 6805 lines in 76 files changed: 6114 ins; 517 del; 174 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

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

From mstrauss at openjdk.org  Sun May  4 14:45:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 May 2025 14:45:01 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v71]
In-Reply-To: <c63EPlN4XFnW4CiMMV4_Rh2B3HyfvH16vfZ6St2MrxE=.a5e53449-c3dc-4c29-a4e9-465ba086e031@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <c63EPlN4XFnW4CiMMV4_Rh2B3HyfvH16vfZ6St2MrxE=.a5e53449-c3dc-4c29-a4e9-465ba086e031@github.com>
Message-ID: <XD5qnQ6YS3MvjO1ly7Zc-gfzwqjOsQxrGWgCYBmzGdU=.431762bf-6258-4200-b147-4a383320139e@github.com>

On Sun, 4 May 2025 10:20:02 GMT, Cormac Redmond <duke at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify header area picking
>
> An even more concise example. Create c:\empty.css and run this, then hover over the window icons and note no style is applied (or is partially applied):
> 
> 
>  @Override
>     public void start(Stage primaryStage) {
>         BorderPane borderPane = new BorderPane();
>         borderPane.setTop(new HeaderBar());
>         Scene scene = new Scene(borderPane, 400, 300);
>         primaryStage.setScene(scene);
>         primaryStage.initStyle(StageStyle.EXTENDED);
>         primaryStage.show();
>         // Calling this once shown, breaks the window decoration (minimise/restore/close) CSS
>         scene.getStylesheets().add(Paths.get("C:\\empty.css").toUri().toString());
>         
>         // Even reproducible on a non-existing file
>         // scene.getStylesheets().add(Paths.get("C:\\i_dont_even_need_to_exist.css").toUri().toString());
>     }

Thanks for finding this bug, @credmond. It should be fixed now.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2849256832

From duke at openjdk.org  Sun May  4 17:08:49 2025
From: duke at openjdk.org (Eric Bresie)
Date: Sun, 4 May 2025 17:08:49 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v14]
In-Reply-To: <nUAKIK8jXvUTA0Yq8q68q2ryhGX_foRTE_2nTrIpfAI=.dd09fd15-39a7-48dd-8e1f-0d5ed26040de@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <nUAKIK8jXvUTA0Yq8q68q2ryhGX_foRTE_2nTrIpfAI=.dd09fd15-39a7-48dd-8e1f-0d5ed26040de@github.com>
Message-ID: <4PRVysd7Wq1OJdkDWo03DjQ3EhNgpnZ2mzU2sikbTpM=.854ef1a3-58ef-447e-b481-21ddb46e4dae@github.com>

On Sun, 4 May 2025 13:46:35 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestStage

Just curious with X11 changes is there any risk of impact to Wayland usage?

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2849317514

From tsayao at openjdk.org  Sun May  4 21:45:30 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 4 May 2025 21:45:30 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v15]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <UVraOSQYLf5NiMJgB5bvm585nTD4PKC7STqEX8EkAKE=.b6de6b3a-a744-4459-8bf5-edbd1bd9c762@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge master
 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	tests/system/src/test/java/test/javafx/scene/RestoreSceneSizeTest.java
 - TestStage
 - - Improve TestStage
   - Notify maximize/fullscreen before show on native side
 - Fix test on SizingTest
 - Remove state precedence tests
 - Use GDK for windowing
 - Remove old comment
 - - Remove unused var
 - - Re-enable DualWindowTest
 - ... and 6 more: https://git.openjdk.org/jfx/compare/498b7e4c...2bc86379

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=14
  Stats: 3970 lines in 28 files changed: 2717 ins; 758 del; 495 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Sun May  4 21:52:51 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 4 May 2025 21:52:51 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v14]
In-Reply-To: <4PRVysd7Wq1OJdkDWo03DjQ3EhNgpnZ2mzU2sikbTpM=.854ef1a3-58ef-447e-b481-21ddb46e4dae@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <nUAKIK8jXvUTA0Yq8q68q2ryhGX_foRTE_2nTrIpfAI=.dd09fd15-39a7-48dd-8e1f-0d5ed26040de@github.com>
 <4PRVysd7Wq1OJdkDWo03DjQ3EhNgpnZ2mzU2sikbTpM=.854ef1a3-58ef-447e-b481-21ddb46e4dae@github.com>
Message-ID: <-h7vty7-G6nByK2ps5IZG8hiYD4y_iiSuMleNrxfXPU=.683bd67e-d923-43e8-9d0b-63625eb998d5@github.com>

On Sun, 4 May 2025 17:06:27 GMT, Eric Bresie <duke at openjdk.org> wrote:

> Just curious with X11 changes is there any risk of impact to Wayland usage?

Since Xorg is being phased out, its the main goal to work well on XWayland (which is the layer that converts the X Protocol to Wayland). Note that native Wayland is still not supported.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2849459312

From kizune at openjdk.org  Mon May  5 08:58:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 5 May 2025 08:58:52 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <ByLpR0uY5VBtBescqrJ4XWqj4p6JByWDISjNoqPg4MY=.63cc4b99-5e74-40da-8459-05496bded86a@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <ByLpR0uY5VBtBescqrJ4XWqj4p6JByWDISjNoqPg4MY=.63cc4b99-5e74-40da-8459-05496bded86a@github.com>
Message-ID: <jvYRQna-d3y-YMWMZ1ZX7sCb0ta_eMr1qO-62i6Edss=.06a0e709-a822-4f99-a09e-b6f6a53d7003@github.com>

On Wed, 30 Apr 2025 21:52:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> How can one test the group protocol change?

Right now the group protocol is only used as a parent protocol for the composite component such as ProgressBar and the only way to properly test it is to add the debugging output to methods such as accessibilityChildren is being called when navigating to the ProgressBar. Later when there will be more composite components the usage will grow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2850339214

From tsayao at openjdk.org  Mon May  5 10:28:09 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 5 May 2025 10:28:09 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v16]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix TestStage conflicting value listener

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/2bc86379..f116775b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=14-15

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

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

From kcr at openjdk.org  Mon May  5 12:59:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 May 2025 12:59:55 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <5YfIzTbfETrOUOrE1ox8JgUOZTOahoDmvmYumVmx-KY=.49738026-ac8c-4134-ba0a-09747cff9254@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <J8RlYJIc9uzXQs2NOAD1aqSQC4vFj9_StvuYbQshaG8=.5c78883a-3e4d-4cc2-8ab4-687cf8c8f5f4@github.com>
 <5YfIzTbfETrOUOrE1ox8JgUOZTOahoDmvmYumVmx-KY=.49738026-ac8c-4134-ba0a-09747cff9254@github.com>
Message-ID: <eEB8vP2PzHRwcVqigxNtXBjgchKCpR4PopxztS1X0fw=.901291f7-8c69-4a1f-8f1d-238e36cde53f@github.com>

On Sat, 3 May 2025 07:22:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I can put the test in the `StylesheetTest` class, which might be more appropriate for this case. what do you think ?
>
>> I can put the test in the `StylesheetTest` class, which might be more appropriate for this case. what do you think ?
> 
> No, because you're not testing the `Stylesheet` class either. What you are doing is testing the Modena theme, for which we have no appropriate testing methodology in JavaFX. I would rather just remove the test entirely, because this new test is going to be another person's future work. It's also more of a change tracker than a unit test, as a style is not a meaningful unit of code. If we want to start testing stylesheets, we should first have a discussion on goals and methodology.

I agree with @mstr2 and @Maran23 that this test should not be in any existing test class. It isn't testing the CSS engine or any particular aspect of stylesheets in general. Rather it is testing an aspect of the `modena.css` stylesheet in particular. I recommend creating a new test class, perhaps under `test.com.sun.javafx.scene.control.skin.modena`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2850914010

From zelmidaoui at openjdk.org  Mon May  5 14:27:17 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 5 May 2025 14:27:17 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v2]
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Created ModenaTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1801/files
  - new: https://git.openjdk.org/jfx/pull/1801/files/9ef0c212..50627c42

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

  Stats: 131 lines in 2 files changed: 98 ins; 33 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1801.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1801/head:pull/1801

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

From kcr at openjdk.org  Mon May  5 14:34:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 May 2025 14:34:52 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v2]
In-Reply-To: <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
Message-ID: <RtdgdjHP21I1yzjuIq4Rf__GJQYyXJcvFkPqZ6GH8vs=.6846c371-7946-4f72-ab36-f7f8b344c0e4@github.com>

On Mon, 5 May 2025 14:27:17 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Created ModenaTest

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 1:

> 1: package test.com.sun.javafx.scene.control.skin.modena;

You need a standard copyright header.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073571915

From angorya at openjdk.org  Mon May  5 14:39:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 14:39:50 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <T7Us2HS5nfqfpWngu34D37PTkCfVJQtCcd-64L9y9wE=.f923eb1e-bf6b-4ea1-bf62-d421e53c799e@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <T7Us2HS5nfqfpWngu34D37PTkCfVJQtCcd-64L9y9wE=.f923eb1e-bf6b-4ea1-bf62-d421e53c799e@github.com>
Message-ID: <xeXqc-tYuvSZlXILcbvvOUJCBkMTaqsikG2OnUAE2w8=.ba09aaff-516b-464d-8671-f8ddae07a348@github.com>

On Mon, 28 Apr 2025 10:30:34 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> A minor comment that the 4 new files require an empty line at the end. and I added another inline query.
> I shall test the change and update.

Looks good, I think the only change requested is @arapte 's end of file newlines

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2851221629

From angorya at openjdk.org  Mon May  5 14:48:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 14:48:53 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v2]
In-Reply-To: <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
Message-ID: <cnTf271DSvSe5WgYIWyuQsFgo0L-7d9TLHEcfVeuMjg=.5104479d-974d-4631-9fa2-c79c1df8dcac@github.com>

On Mon, 5 May 2025 14:27:17 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Created ModenaTest

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 23:

> 21: import static org.junit.jupiter.api.Assertions.fail;
> 22: 
> 23: public class ModenaTest {

perhaps add a javadoc describing what this file is supposed to test?

modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 33:

> 31:     }
> 32: 
> 33:     private TextInputControl textInput;

Since this test tests `modena.css` aspects of the `TextInputControl` class hierarchy, should this test be renamed then (`TextInputControlModena` or something like that)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073598355
PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073597590

From zelmidaoui at openjdk.org  Mon May  5 17:37:31 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 5 May 2025 17:37:31 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v3]
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <uHV8vTurNgNX3DsEw1qfZBH_7kjcvHkeT3LRVJ15XUY=.95b99e63-91c3-42d0-8ec5-d170fb47f5d5@github.com>

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:

 - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
 - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1801/files
  - new: https://git.openjdk.org/jfx/pull/1801/files/50627c42..7320ee66

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

  Stats: 237 lines in 2 files changed: 139 ins; 98 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1801.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1801/head:pull/1801

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

From zelmidaoui at openjdk.org  Mon May  5 17:37:31 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 5 May 2025 17:37:31 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v2]
In-Reply-To: <RtdgdjHP21I1yzjuIq4Rf__GJQYyXJcvFkPqZ6GH8vs=.6846c371-7946-4f72-ab36-f7f8b344c0e4@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
 <RtdgdjHP21I1yzjuIq4Rf__GJQYyXJcvFkPqZ6GH8vs=.6846c371-7946-4f72-ab36-f7f8b344c0e4@github.com>
Message-ID: <A6RBU4L34yj03NS_fDDYXCixfnTXySzvwZkRzw9nwWI=.8ad85762-deb5-4a01-9198-418c636c9b42@github.com>

On Mon, 5 May 2025 14:32:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Created ModenaTest
>
> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 1:
> 
>> 1: package test.com.sun.javafx.scene.control.skin.modena;
> 
> You need a standard copyright header.

Added it, thanks

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073872524

From zelmidaoui at openjdk.org  Mon May  5 17:37:31 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 5 May 2025 17:37:31 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v2]
In-Reply-To: <cnTf271DSvSe5WgYIWyuQsFgo0L-7d9TLHEcfVeuMjg=.5104479d-974d-4631-9fa2-c79c1df8dcac@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <XjgKE7-iJQsP9EigrmkIBMdPWb1gsMM5QcMeH-KGRVQ=.4a75ab74-292e-4bbb-88f1-643d56ec7268@github.com>
 <cnTf271DSvSe5WgYIWyuQsFgo0L-7d9TLHEcfVeuMjg=.5104479d-974d-4631-9fa2-c79c1df8dcac@github.com>
Message-ID: <HkQtOAg08OOdCk0QdfAQvlmD9M4FWIpnuujUFtoh5X4=.d2541c6e-941f-4081-8f18-d48c48458700@github.com>

On Mon, 5 May 2025 14:46:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Created ModenaTest
>
> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 23:
> 
>> 21: import static org.junit.jupiter.api.Assertions.fail;
>> 22: 
>> 23: public class ModenaTest {
> 
> perhaps add a javadoc describing what this file is supposed to test?

I did add it

> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/skin/modena/ModenaTest.java line 33:
> 
>> 31:     }
>> 32: 
>> 33:     private TextInputControl textInput;
> 
> Since this test tests `modena.css` aspects of the `TextInputControl` class hierarchy, should this test be renamed then (`TextInputControlModena` or something like that)?

Yes found that more convenient and changed the name to TextInputControlModena, we can use this class to test modena.css for `TextInputControl`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073877269
PR Review Comment: https://git.openjdk.org/jfx/pull/1801#discussion_r2073876319

From angorya at openjdk.org  Mon May  5 17:59:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 17:59:57 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v3]
In-Reply-To: <uHV8vTurNgNX3DsEw1qfZBH_7kjcvHkeT3LRVJ15XUY=.95b99e63-91c3-42d0-8ec5-d170fb47f5d5@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <uHV8vTurNgNX3DsEw1qfZBH_7kjcvHkeT3LRVJ15XUY=.95b99e63-91c3-42d0-8ec5-d170fb47f5d5@github.com>
Message-ID: <B6Yc44CcdHiLrpi30CuoZynDg1BvreD1D4t3Yw2aBiI=.03918388-7ec8-47f6-99b9-9adb1d9d5148@github.com>

On Mon, 5 May 2025 17:37:31 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1801#pullrequestreview-2815626315

From angorya at openjdk.org  Mon May  5 18:03:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 18:03:53 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <XOLBWHYODg_1owp6QAMTy-ALlsySSJAm_-7pEdv3k80=.977fc2d6-5b1f-4f25-95fc-3e47c0fbe126@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <Th1oOlzh9i6tpRu0CnlU8Ps5yHaMTyc3qUOAh3CswZY=.92d0611c-f094-467f-8222-3223c0f5ef18@github.com>
 <XOLBWHYODg_1owp6QAMTy-ALlsySSJAm_-7pEdv3k80=.977fc2d6-5b1f-4f25-95fc-3e47c0fbe126@github.com>
Message-ID: <hKK8iH7bo6fsZXCUKFEkSPLDDw5CHkG0VU9Vw3EnxvU=.0e4a7cd8-08e5-4d6c-8707-9b3de79b9756@github.com>

On Sat, 3 May 2025 08:52:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> if it doesn't match, the rule doesn't apply.

and if does apply, it overrides any previous rules (but can be overridden by any subsequent rules), right?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2851879240

From mstrauss at openjdk.org  Mon May  5 18:19:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 5 May 2025 18:19:01 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <hKK8iH7bo6fsZXCUKFEkSPLDDw5CHkG0VU9Vw3EnxvU=.0e4a7cd8-08e5-4d6c-8707-9b3de79b9756@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <Th1oOlzh9i6tpRu0CnlU8Ps5yHaMTyc3qUOAh3CswZY=.92d0611c-f094-467f-8222-3223c0f5ef18@github.com>
 <XOLBWHYODg_1owp6QAMTy-ALlsySSJAm_-7pEdv3k80=.977fc2d6-5b1f-4f25-95fc-3e47c0fbe126@github.com>
 <hKK8iH7bo6fsZXCUKFEkSPLDDw5CHkG0VU9Vw3EnxvU=.0e4a7cd8-08e5-4d6c-8707-9b3de79b9756@github.com>
Message-ID: <fDmf12k-cYRnxIgphdtb4c2zSzSQsVhhOcb_pSfUHGU=.809e6c0e-7497-4383-b0d8-c45b85e8e797@github.com>

On Mon, 5 May 2025 18:00:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> and if does apply, it overrides any previous rules (but can be overridden by any subsequent rules), right?

Yes, if the media query matches, it's as if the enclosed rule was a normal rule at that position in the stylesheet.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2851918954

From angorya at openjdk.org  Mon May  5 18:56:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 18:56:02 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
Message-ID: <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>

On Sat, 3 May 2025 08:56:07 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 30 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - cssref doc
>  - Merge branch 'master' into feature/media-queries
>  - reorder fields
>  - remove ReadOnlyBooleanWrapper
>  - Scene preferences only actively observe platform preferences when the scene is showing
>  - formatting
>  - typo
>  - use equality instead of identity
>  - rename TokenStream methods
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d

first batch of comments.  more to follow.

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/media-query.svg line 2:

> 1: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> 2: <svg

just an observation: these images look blurry on my mac external monitor (scale=1) relative to the w3.org ones (on the left):

![Screenshot 2025-05-05 at 08 06 36](https://github.com/user-attachments/assets/8ba6fe7b-ec1c-4297-b6ce-0796a314e9aa)

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 184:

> 182: 
> 183:             for (DeferredProperty<?> property : deferredProperties.values()) {
> 184:                 property.fireValueChangedIfNecessary();

firing events from a synchronized method is a recipe for a lockup.
JavaFX is still a single threaded toolkit (if we ignore the creation of certain objects aspect), why do we want to synchronize?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 103:

> 101:                 default -> {
> 102:                     errorHandler.accept(stream.current(), "Unexpected token");
> 103:                     return expressions;

is this needed?  (see L108)

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 273:

> 271:     }
> 272: 
> 273:     private static final Predicate<Token> IDENT = token -> token.getType() == CssLexer.IDENT;

personal preference: I'd rather see these up front.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuerySerializer.java line 72:

> 70:                                    DataOutputStream os,
> 71:                                    StyleConverter.StringStore stringStore) throws IOException {
> 72:         os.writeByte(QueryType.of(mediaQuery).ordinal());

potential problem:
someone may insert/reorder QueryType enums and break backward compatibility.
at a minimum, a warning comment should be added to QueryType, or perhaps some more reliable code in read/writeBinary?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuerySerializer.java line 104:

> 102: 
> 103:     public static MediaQuery readBinary(DataInputStream is, String[] strings) throws IOException {
> 104:         return switch (QueryType.VALUES[is.readByte()]) {

same issue with backward compatibility - what if an old core tries to read the newer format and AIOOBE is thrown instead of IOException?  Should we validate first and throw IOE instead?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 48:

> 46:         this.queries = List.copyOf(queries);
> 47:         this.parent = parent;
> 48:         this.hash = queries.hashCode();

I would rather see `this.queries.hasCode()` here

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 52:

> 50: 
> 51:     /**
> 52:      * Returns the list of media queries.

should we say "immutable"?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 118:

> 116:         boolean hasParent = stream.readBoolean();
> 117: 
> 118:         return new MediaRule(List.of(queries), hasParent ? readBinary(stream, strings) : null);

the exceptions in java have improved, but there is 3 statements in this line.
anyone who ever debugged code after the fact using two-week old logs would say: please keep one statement per line, if possible.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 123:

> 121:     @Override
> 122:     public boolean equals(Object obj) {
> 123:         return obj instanceof MediaRule rule && rule.getQueries().equals(queries);

should we add `if(obj == this)` as we usually do?
also, `parent` is missing in the check

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/ConjunctionExpression.java line 67:

> 65:     @Override
> 66:     public String toString() {
> 67:         return "(" + left.toString() + " and " + right.toString() + ")";

`return "(" + left + " and " + right + ")";`

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/DisjunctionExpression.java line 67:

> 65:     @Override
> 66:     public String toString() {
> 67:         return "(" + left.toString() + " or " + right.toString() + ")";

`return "(" + left + " or " + right + ")";`

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 58:

> 56:     @Override
> 57:     public boolean equals(Object obj) {
> 58:         return obj instanceof FunctionExpression<?> expr

`if(obj == this)` ?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 66:

> 64:     @Override
> 65:     public int hashCode() {
> 66:         return Objects.hash(featureName, featureValue, value);

very minor: maybe add `FunctionExpression.class` to the mix?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssLexer.java line 34:

> 32: 
> 33: public final class CssLexer {
> 34:     public final static int STRING = 10;

minor: `public static final` maybe?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 73:

> 71:     }
> 72: 
> 73:     public void reconsume() {

maybe a javadoc would suffice if you like the name so much

modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 103:

> 101:         } finally {
> 102:             currentIndex = index;
> 103:             currentItem = index >= 0 ? source.get(index) : null;

general question: will this `finally` block work as expected if an exception happened somewhere in the `try` block?

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4339:

> 4337: 
> 4338:                 currentToken = nextToken(lexer);
> 4339:                 expectedRBraces--;

what happens in case of unbalanced braces and `expectedRBraces` < 0 ?

modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 384:

> 382:         MediaRule mediaRule = null;
> 383: 
> 384:         if (bssVersion >= 7) {

please add a comment pointing to Stylesheet.BINARY_CSS_VERSION.

Ideally, there would be constants declared somewhere with explanation instead of the magic number '7'

modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 67:

> 65:      * Version 5: persist @font-face
> 66:      * Version 6: converter classes moved to public package
> 67:      * Version 7: media queries

this, in my opinion, deserves a constant (it does not have to be public).

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

> 6591:          * @see #setPersistentScrollBars(Boolean)
> 6592:          */
> 6593:         boolean isPersistentScrollBars();

do these accessors need individual javadocs?

modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 295:

> 293: 
> 294:     @Test
> 295:     void parserRecoversWhenMediaQueryIsMalformed() {

should we also test malformed queries like `not not`, `and or` etc.?

also, unbalanced parentheses?

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2813024498
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073642689
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073651690
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073669724
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073756253
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073932495
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073934605
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073937065
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073937476
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073940636
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073942208
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073950949
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073952052
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073953939
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073956250
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073959700
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073965466
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073967786
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073978797
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073985918
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073989278
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073992865
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073676691

From angorya at openjdk.org  Mon May  5 18:56:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 18:56:04 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
Message-ID: <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>

On Mon, 28 Apr 2025 07:38:37 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 28 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - reorder fields
>  - remove ReadOnlyBooleanWrapper
>  - Scene preferences only actively observe platform preferences when the scene is showing
>  - formatting
>  - typo
>  - use equality instead of identity
>  - rename TokenStream methods
>  - improved implementation of NullCoalescingPropertyBase
>  - small refactor
>  - ... and 18 more: https://git.openjdk.org/jfx/compare/3fdd2138...32abb8a3

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 838:

> 836:         An empty media query list evaluates to <code>true</code>.
> 837:         <figure style="margin: 0">
> 838:             <img src="media-query.svg" width="210" alt="Media Query List">

did you create these images yourself?

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 871:

> 869:             <code>(prefers-color-scheme: dark) and (prefers-reduced-motion) or (prefers-reduced-transparency)</code>
> 870:             is illegal, as it is unclear what was meant. In this case, parentheses must be used to group expressions.
> 871:     </ul>

maybe one or two examples would be helpful here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2072225901
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2072227142

From angorya at openjdk.org  Mon May  5 18:56:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 18:56:04 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
Message-ID: <-XCS597GFog5Rg2dknGhN0xZDWRCHXy1Fa930HivAw8=.670e6355-2315-4d92-8d8f-5d9a191147f6@github.com>

On Mon, 5 May 2025 18:08:57 GMT, Andy Goryachev <angorya 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 30 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - cssref doc
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuerySerializer.java line 72:
> 
>> 70:                                    DataOutputStream os,
>> 71:                                    StyleConverter.StringStore stringStore) throws IOException {
>> 72:         os.writeByte(QueryType.of(mediaQuery).ordinal());
> 
> potential problem:
> someone may insert/reorder QueryType enums and break backward compatibility.
> at a minimum, a warning comment should be added to QueryType, or perhaps some more reliable code in read/writeBinary?

or perhaps use hard-coded values instead 'c', 'f', 'C', 'd', 'n' ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073935721

From angorya at openjdk.org  Mon May  5 18:56:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 18:56:05 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <jlPI_eqMSiPEkFIxt11ZWnW9Qpw6QdKuJamw7wtqhdo=.06f3a435-629b-4d5b-8ee1-ab54bdd913f7@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9U5TJOMXb3oMWWijiRzo0lp7FJZIQPl-PkRJ3Rc-IqA=.959a8ee1-b84e-46ba-8dec-96c2dd7af9aa@github.com>
 <DPskwba6n5Lnw-CyzsM8U6zNhBW36cNHwUyGSCT9fcg=.4e1610c2-fd95-4805-b8fa-87c533b6a107@github.com>
 <jlPI_eqMSiPEkFIxt11ZWnW9Qpw6QdKuJamw7wtqhdo=.06f3a435-629b-4d5b-8ee1-ab54bdd913f7@github.com>
Message-ID: <WAMBjQlCaiR-XebZ1LYQESliCxMastUMK95tnmy_eBk=.b416d765-3b1a-4363-9b76-7266e8533424@github.com>

On Mon, 14 Apr 2025 12:56:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 129:
>> 
>>> 127:     public int hashCode() {
>>> 128:         return hash;
>>> 129:     }
>> 
>> You're basically saying here that a media rule with or without parent but the same queries is the same.  However, parent is taken into account while writing/reading and evaluating.  I think this deserves a justification.
>
> I might just remove `equals()`/`hashCode()`, because the class is not used in a way where equality would be relevant.

As far as I can tell, MediaRule is not exposed publicly, neither it's put into a hashtable, so we might as well remove `hash`, `hashCode()` and `equals()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2073949073

From andy.goryachev at oracle.com  Mon May  5 19:09:18 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 5 May 2025 19:09:18 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
Message-ID: <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>

Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250505/b79f32ba/attachment-0001.htm>

From pavelturk2000 at gmail.com  Mon May  5 19:47:01 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 5 May 2025 22:47:01 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>

Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel


On 5/5/25 22:09, Andy Goryachev wrote:
>
> Dear Pavel:
>
> Can you clarify what you are trying to do exactly?
>
> If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
> If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS. There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Saturday, May 3, 2025 at 10:07
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *CodeArea: -fx-background-color doesn't work.
>
> For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
> Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
> Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
> they?have?-rtfx-background-color.
>
> public?class?JfxCodeArea?extends?Application?{
>
> ?????@Override
> ?????public?void?start(Stage?primaryStage)?throws?Exception?{
> ?????????String?text?=?"""
> ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
> ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
> ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
> ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
> ???????????????????????""";
>
> ?????????String?css?=?"""
> ?????????????.test?{
> ?????????????????-fx-font-weight:?bold;
> ?????????????????-fx-fill:?red;
> ?????????????????-fx-background-color:?green;
> ?????????????}
>
> ?????????""";
> ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
> ?????????CodeArea?codeArea?=?new?CodeArea();
> ?????????codeArea.getStylesheets().add(data);
>
> ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
> ?????????????@Override
> ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
> ?????????????????var?builder?=?RichParagraph.builder();
> ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
> ?????????????????return?builder.build();
> ?????????????}
>
> ?????????????@Override
> ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
> ?????????????}
> ?????????});
>
> ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
> ?????????var?button?=?new?Button("Go!");
> ?????????button.setOnAction(e?->?codeArea.setText(text));
> ?????????VBox?root?=?new?VBox(codeArea,?button);
> ?????????Scene?scene?=?new?Scene(root,?600,?200);
> ?????????primaryStage.setScene(scene);
> ?????????primaryStage.show();
>
> ?????}
>
> ?????public?static?void?main(String[]?args)?{
> ?????????launch(args);
> ?????}
> }
>
> Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250505/08c8105d/attachment.htm>

From andy.goryachev at oracle.com  Mon May  5 19:54:52 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 5 May 2025 19:54:52 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
Message-ID: <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>

You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel

On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel

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

From pavelturk2000 at gmail.com  Mon May  5 20:10:10 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 5 May 2025 23:10:10 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>

Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel

On 5/5/25 22:54, Andy Goryachev wrote:
>
> You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
> JDK-8355774 is pretty high on my list of things to do.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 5, 2025 at 12:47
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> Hello, Andy
>
> Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
> I have just opened an issue with ID : 9078469.
>
> Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
> that it's impossible to work without it.
>
> Best regards, Pavel
>
> On 5/5/25 22:09, Andy Goryachev wrote:
>
>     Dear Pavel:
>
>     Can you clarify what you are trying to do exactly?
>
>     If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>     If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.? There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Saturday, May 3, 2025 at 10:07
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *CodeArea: -fx-background-color doesn't work.
>
>     For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>     Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>     Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>     they?have?-rtfx-background-color.
>
>     public?class?JfxCodeArea?extends?Application?{
>
>     ?????@Override
>     ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>     ?????????String?text?=?"""
>     ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>     ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>     ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>     ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>     ???????????????????????""";
>
>     ?????????String?css?=?"""
>     ?????????????.test?{
>     ?????????????????-fx-font-weight:?bold;
>     ?????????????????-fx-fill:?red;
>     ?????????????????-fx-background-color:?green;
>     ?????????????}
>
>     ?????????""";
>     ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>     ?????????CodeArea?codeArea?=?new?CodeArea();
>     ?????????codeArea.getStylesheets().add(data);
>
>     ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>     ?????????????@Override
>     ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>     ?????????????????var?builder?=?RichParagraph.builder();
>     ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>     ?????????????????return?builder.build();
>     ?????????????}
>
>     ?????????????@Override
>     ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>     ?????????????}
>     ?????????});
>
>     ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>     ?????????var?button?=?new?Button("Go!");
>     ?????????button.setOnAction(e?->?codeArea.setText(text));
>     ?????????VBox?root?=?new?VBox(codeArea,?button);
>     ?????????Scene?scene?=?new?Scene(root,?600,?200);
>     ?????????primaryStage.setScene(scene);
>     ?????????primaryStage.show();
>
>     ?????}
>
>     ?????public?static?void?main(String[]?args)?{
>     ?????????launch(args);
>     ?????}
>     }
>
>     Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250505/9e4e6e56/attachment.htm>

From andy.goryachev at oracle.com  Mon May  5 20:20:55 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 5 May 2025 20:20:55 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
Message-ID: <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>

Right, the API are missing currently.  I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.  Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.  Right?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:10
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel
On 5/5/25 22:54, Andy Goryachev wrote:
You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel
On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel


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

From angorya at openjdk.org  Mon May  5 20:46:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 20:46:54 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
Message-ID: <oqI2pikgqFnR45CWiX7YbTVjcx2UZMg9RTxscKfF4QY=.1fd0030d-9cab-4dc8-8c7c-21541b1defe5@github.com>

On Sat, 3 May 2025 08:56:07 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 30 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - cssref doc
>  - Merge branch 'master' into feature/media-queries
>  - reorder fields
>  - remove ReadOnlyBooleanWrapper
>  - Scene preferences only actively observe platform preferences when the scene is showing
>  - formatting
>  - typo
>  - use equality instead of identity
>  - rename TokenStream methods
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d

Should this work?


@media (prefers-color-scheme: dark) and not (prefers-persistent-scrollbars) {
  .root {
    -fx-accent: yellow;
  }
}


(it does not, writes to stderr):


WARNING: CSS Error parsing '@media (prefers-color-scheme: dark) and not (prefers-persistent-scrollbars) {
  .root {
    -fx-accent: yellow;
  }
}: Expected LPAREN at [1,40]

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/media/MediaQuerySerializerTest.java line 46:

> 44: import static org.junit.jupiter.api.Assertions.*;
> 45: 
> 46: public class MediaQuerySerializerTest {

just a thought: this could have been a parameterized test (this version is ok though).

modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssLexerTest.java line 47:

> 45:     }
> 46: 
> 47:     private void checkTokens(List<Token> resultTokens, Token... expectedTokens) {

should there be new tests in `CssLexerTest` for the `@media` queries?

modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 185:

> 183:     @Test
> 184:     void disjunctionAndConjunctionCanNotBeCombined() {
> 185:         Stylesheet stylesheet = new CssParser().parse("""

could we also test for "or not" and "and not" ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2852289887
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074112314
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074118560
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074127483

From angorya at openjdk.org  Mon May  5 20:52:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 May 2025 20:52:54 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
Message-ID: <JbmQWswxQvgRIZRwXfUyo97eCI9J8aLTfXE99BBzhtQ=.4f84e40c-910f-429c-8429-8bfc3651bf87@github.com>

On Sat, 3 May 2025 08:56:07 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 30 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - cssref doc
>  - Merge branch 'master' into feature/media-queries
>  - reorder fields
>  - remove ReadOnlyBooleanWrapper
>  - Scene preferences only actively observe platform preferences when the scene is showing
>  - formatting
>  - typo
>  - use equality instead of identity
>  - rename TokenStream methods
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 216:

> 214: 
> 215:             if (tokens.consumeIf(RPAREN) == null) {
> 216:                 errorHandler.accept(tokens.consume(), "Expected RPAREN");

RPAREN -> right parenthesis ')'?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 223:

> 221:         }
> 222: 
> 223:         errorHandler.accept(tokens.consume(), "Expected LPAREN");

LPAREN -> left parenthesis ')'?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 241:

> 239:     private MediaQuery parseMediaFeature(TokenStream tokens) {
> 240:         if (tokens.consumeIf(LPAREN) == null) {
> 241:             errorHandler.accept(tokens.consume(), "Expected LPAREN");

LPAREN?
also LL247, 259

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074166798
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074167103
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074167504

From pavelturk2000 at gmail.com  Mon May  5 20:59:23 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 5 May 2025 23:59:23 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>

To be as clear as possible, here's what I need:

.test {
 ???? -fx-set-somehow-background-color: green;
}

var builder = RichParagraph.builder();
builder.addWithStyleNames(segment, "test");

because, in parallel for RTFX I simply use its stylesheet:

.test {
 ???? -rtfx-background-color: green;
}


So, for both code areas, I use same style classes for styling paragraph segments.

Best regards, Pavel

On 5/5/25 23:20, Andy Goryachev wrote:
>
> Right, the API are missing currently.? I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.? Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.? Right?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 5, 2025 at 13:10
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> Andy, thank you very much for your help.
>
> That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
> and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.
>
> Well, technically I could, but it just wouldn?t make any sense.
>
> Best regards, Pavel
>
> On 5/5/25 22:54, Andy Goryachev wrote:
>
>     You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
>     JDK-8355774 is pretty high on my list of things to do.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 5, 2025 at 12:47
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>     Hello, Andy
>
>     Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
>     I have just opened an issue with ID : 9078469.
>
>     Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
>     that it's impossible to work without it.
>
>     Best regards, Pavel
>
>     On 5/5/25 22:09, Andy Goryachev wrote:
>
>         Dear Pavel:
>
>         Can you clarify what you are trying to do exactly?
>
>         If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>         If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.? There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Saturday, May 3, 2025 at 10:07
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *CodeArea: -fx-background-color doesn't work.
>
>         For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>         Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>         Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>         they?have?-rtfx-background-color.
>
>         public?class?JfxCodeArea?extends?Application?{
>
>         ?????@Override
>         ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>         ?????????String?text?=?"""
>         ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>         ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>         ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>         ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>         ???????????????????????""";
>
>         ?????????String?css?=?"""
>         ?????????????.test?{
>         ?????????????????-fx-font-weight:?bold;
>         ?????????????????-fx-fill:?red;
>         ?????????????????-fx-background-color:?green;
>         ?????????????}
>
>         ?????????""";
>         ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>         ?????????CodeArea?codeArea?=?new?CodeArea();
>         ?????????codeArea.getStylesheets().add(data);
>
>         ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>         ?????????????@Override
>         ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>         ?????????????????var?builder?=?RichParagraph.builder();
>         ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>         ?????????????????return?builder.build();
>         ?????????????}
>
>         ?????????????@Override
>         ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>         ?????????????}
>         ?????????});
>
>         ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>         ?????????var?button?=?new?Button("Go!");
>         ?????????button.setOnAction(e?->?codeArea.setText(text));
>         ?????????VBox?root?=?new?VBox(codeArea,?button);
>         ?????????Scene?scene?=?new?Scene(root,?600,?200);
>         ?????????primaryStage.setScene(scene);
>         ?????????primaryStage.show();
>
>         ?????}
>
>         ?????public?static?void?main(String[]?args)?{
>         ?????????launch(args);
>         ?????}
>         }
>
>         Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250505/a71caa84/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon May  5 21:04:20 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 5 May 2025 21:04:20 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
Message-ID: <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>

Will not happen.  CSS compatibility with a third party library is not a requirement in this case.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:59
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
To be as clear as possible, here's what I need:

.test {
     -fx-set-somehow-background-color: green;
}

var builder = RichParagraph.builder();
builder.addWithStyleNames(segment, "test");

because, in parallel for RTFX I simply use its stylesheet:

.test {
     -rtfx-background-color: green;
}


So, for both code areas, I use same style classes for styling paragraph segments.

Best regards, Pavel
On 5/5/25 23:20, Andy Goryachev wrote:
Right, the API are missing currently.  I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.  Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.  Right?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:10
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel
On 5/5/25 22:54, Andy Goryachev wrote:
You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel
On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel



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

From pavelturk2000 at gmail.com  Mon May  5 21:12:52 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 6 May 2025 00:12:52 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>

No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
'-fx-background-color' for RichParagraph segment.

I've opened an issue today, so, when it is approved there won't be any questions.

Best regards, Pavel

On 5/6/25 00:04, Andy Goryachev wrote:
>
> Will not happen.? CSS compatibility with a third party library is not a requirement in this case.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 5, 2025 at 13:59
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> To be as clear as possible, here's what I need:
>
> .test {
> ???? -fx-set-somehow-background-color: green;
> }
>
> var builder = RichParagraph.builder();
> builder.addWithStyleNames(segment, "test");
>
> because, in parallel for RTFX I simply use its stylesheet:
>
> .test {
> ???? -rtfx-background-color: green;
> }
>
>
> So, for both code areas, I use same style classes for styling paragraph segments.
>
> Best regards, Pavel
>
> On 5/5/25 23:20, Andy Goryachev wrote:
>
>     Right, the API are missing currently.? I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.? Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.? Right?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 5, 2025 at 13:10
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>     Andy, thank you very much for your help.
>
>     That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
>     and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.
>
>     Well, technically I could, but it just wouldn?t make any sense.
>
>     Best regards, Pavel
>
>     On 5/5/25 22:54, Andy Goryachev wrote:
>
>         You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
>         JDK-8355774 is pretty high on my list of things to do.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Monday, May 5, 2025 at 12:47
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>         Hello, Andy
>
>         Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
>         I have just opened an issue with ID : 9078469.
>
>         Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
>         that it's impossible to work without it.
>
>         Best regards, Pavel
>
>         On 5/5/25 22:09, Andy Goryachev wrote:
>
>             Dear Pavel:
>
>             Can you clarify what you are trying to do exactly?
>
>             If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>             If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.? There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Saturday, May 3, 2025 at 10:07
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *CodeArea: -fx-background-color doesn't work.
>
>             For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>             Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>             Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>             they?have?-rtfx-background-color.
>
>             public?class?JfxCodeArea?extends?Application?{
>
>             ?????@Override
>             ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>             ?????????String?text?=?"""
>             ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>             ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>             ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>             ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>             ???????????????????????""";
>
>             ?????????String?css?=?"""
>             ?????????????.test?{
>             ?????????????????-fx-font-weight:?bold;
>             ?????????????????-fx-fill:?red;
>             ?????????????????-fx-background-color:?green;
>             ?????????????}
>
>             ?????????""";
>             ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>             ?????????CodeArea?codeArea?=?new?CodeArea();
>             ?????????codeArea.getStylesheets().add(data);
>
>             ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>             ?????????????@Override
>             ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>             ?????????????????var?builder?=?RichParagraph.builder();
>             ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>             ?????????????????return?builder.build();
>             ?????????????}
>
>             ?????????????@Override
>             ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>             ?????????????}
>             ?????????});
>
>             ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>             ?????????var?button?=?new?Button("Go!");
>             ?????????button.setOnAction(e?->?codeArea.setText(text));
>             ?????????VBox?root?=?new?VBox(codeArea,?button);
>             ?????????Scene?scene?=?new?Scene(root,?600,?200);
>             ?????????primaryStage.setScene(scene);
>             ?????????primaryStage.show();
>
>             ?????}
>
>             ?????public?static?void?main(String[]?args)?{
>             ?????????launch(args);
>             ?????}
>             }
>
>             Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250506/df87a863/attachment-0001.htm>

From zelmidaoui at openjdk.org  Mon May  5 21:28:08 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 5 May 2025 21:28:08 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v4]
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

Ziad El Midaoui 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 five additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8355012.modenaCss
 - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
 - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
 - Created ModenaTest
 - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1801/files
  - new: https://git.openjdk.org/jfx/pull/1801/files/7320ee66..e3ad18c0

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

  Stats: 123781 lines in 294 files changed: 29355 ins; 52007 del; 42419 mod
  Patch: https://git.openjdk.org/jfx/pull/1801.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1801/head:pull/1801

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

From mstrauss at openjdk.org  Tue May  6 04:51:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 04:51:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
Message-ID: <XwxVvPfMwHL3k5DQV3EvGILY_3xYU-YJLL2noRUJ_20=.0682483b-e216-4d4c-ade7-b0187c07feba@github.com>

On Fri, 2 May 2025 23:03:50 GMT, Andy Goryachev <angorya 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 28 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - improved implementation of NullCoalescingPropertyBase
>>  - small refactor
>>  - ... and 18 more: https://git.openjdk.org/jfx/compare/3fdd2138...32abb8a3
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 838:
> 
>> 836:         An empty media query list evaluates to <code>true</code>.
>> 837:         <figure style="margin: 0">
>> 838:             <img src="media-query.svg" width="210" alt="Media Query List">
> 
> did you create these images yourself?

Yes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074729229

From mstrauss at openjdk.org  Tue May  6 06:52:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 06:52:36 GMT
Subject: RFR: 8345348: CSS media feature queries [v22]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <kr-0opfStia1kRc4WsH_irZnD4eUIputXMDPFa3rqjU=.5f7228e4-fa49-46ee-959c-3bceba18be72@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with four additional commits since the last revision:

 - review comments
 - added tests
 - documentation
 - use serializedId in MediaQuerySerializer

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/626a904d..0848e6b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=21
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=20-21

  Stats: 147 lines in 8 files changed: 109 ins; 25 del; 13 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 May  6 06:52:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 06:52:38 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
Message-ID: <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>

On Mon, 5 May 2025 15:28:30 GMT, Andy Goryachev <angorya 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 30 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - cssref doc
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQueryParser.java line 103:
> 
>> 101:                 default -> {
>> 102:                     errorHandler.accept(stream.current(), "Unexpected token");
>> 103:                     return expressions;
> 
> is this needed?  (see L108)

The return statement? Yes, we want token processing to stop here if we encounter an unexpected token, as there's no recovery strategy at this point.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuerySerializer.java line 104:
> 
>> 102: 
>> 103:     public static MediaQuery readBinary(DataInputStream is, String[] strings) throws IOException {
>> 104:         return switch (QueryType.VALUES[is.readByte()]) {
> 
> same issue with backward compatibility - what if an old core tries to read the newer format and AIOOBE is thrown instead of IOException?  Should we validate first and throw IOE instead?

That would be forward compatibility, which is not supported. JavaFX will not even try to load a binary file with a higher version than it can understand, and error out immediately (see Stylesheet.java:L317).

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 48:
> 
>> 46:         this.queries = List.copyOf(queries);
>> 47:         this.parent = parent;
>> 48:         this.hash = queries.hashCode();
> 
> I would rather see `this.queries.hasCode()` here

I've removed it instead.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 118:
> 
>> 116:         boolean hasParent = stream.readBoolean();
>> 117: 
>> 118:         return new MediaRule(List.of(queries), hasParent ? readBinary(stream, strings) : null);
> 
> the exceptions in java have improved, but there is 3 statements in this line.
> anyone who ever debugged code after the fact using two-week old logs would say: please keep one statement per line, if possible.

I usually don't follow dogma. That being said, I moved the parent-rule expression out of line.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaRule.java line 123:
> 
>> 121:     @Override
>> 122:     public boolean equals(Object obj) {
>> 123:         return obj instanceof MediaRule rule && rule.getQueries().equals(queries);
> 
> should we add `if(obj == this)` as we usually do?
> also, `parent` is missing in the check

This is now removed.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 66:
> 
>> 64:     @Override
>> 65:     public int hashCode() {
>> 66:         return Objects.hash(featureName, featureValue, value);
> 
> very minor: maybe add `FunctionExpression.class` to the mix?

Why?

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssLexer.java line 34:
> 
>> 32: 
>> 33: public final class CssLexer {
>> 34:     public final static int STRING = 10;
> 
> minor: `public static final` maybe?

I want to keep the diffs minimal here, because I didn't change anything except making the constants public.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 73:
> 
>> 71:     }
>> 72: 
>> 73:     public void reconsume() {
> 
> maybe a javadoc would suffice if you like the name so much

I've added javadocs to all methods. By the way, I don't really get the opposition to the name. The arguments presented so far do not convince me to drop CSS lingo.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 103:
> 
>> 101:         } finally {
>> 102:             currentIndex = index;
>> 103:             currentItem = index >= 0 ? source.get(index) : null;
> 
> general question: will this `finally` block work as expected if an exception happened somewhere in the `try` block?

That's its purpose. It will reset the stream back to the state it was in before the `matches(...)` method was called.

> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4339:
> 
>> 4337: 
>> 4338:                 currentToken = nextToken(lexer);
>> 4339:                 expectedRBraces--;
> 
> what happens in case of unbalanced braces and `expectedRBraces` < 0 ?

The behavior is the same as with a normal unbalanced curly brace. I've added a test for it.

> modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 384:
> 
>> 382:         MediaRule mediaRule = null;
>> 383: 
>> 384:         if (bssVersion >= 7) {
> 
> please add a comment pointing to Stylesheet.BINARY_CSS_VERSION.
> 
> Ideally, there would be constants declared somewhere with explanation instead of the magic number '7'

I've added comments to that effect.

> modules/javafx.graphics/src/main/java/javafx/css/Stylesheet.java line 67:
> 
>> 65:      * Version 5: persist @font-face
>> 66:      * Version 6: converter classes moved to public package
>> 67:      * Version 7: media queries
> 
> this, in my opinion, deserves a constant (it does not have to be public).

I'd rather do this in a refactor PR with the rest of the magic numbers.

> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6593:
> 
>> 6591:          * @see #setPersistentScrollBars(Boolean)
>> 6592:          */
>> 6593:         boolean isPersistentScrollBars();
> 
> do these accessors need individual javadocs?

Yes, because the javadoc tool doesn't recognize a method that returns `boolean` as a getter for `ObjectProperty<Boolean>` (it expects `BooleanProperty`). This is a null-coalescing property: you can set it to `null`, but it will always evaluate to `true` or `false`, so it doesn't make sense to return `Boolean` from its getter.

> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/media/MediaQuerySerializerTest.java line 46:
> 
>> 44: import static org.junit.jupiter.api.Assertions.*;
>> 45: 
>> 46: public class MediaQuerySerializerTest {
> 
> just a thought: this could have been a parameterized test (this version is ok though).

Yes, with the downside that parameterized tests are usually a bit harder to debug in isolation.

> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssLexerTest.java line 47:
> 
>> 45:     }
>> 46: 
>> 47:     private void checkTokens(List<Token> resultTokens, Token... expectedTokens) {
> 
> should there be new tests in `CssLexerTest` for the `@media` queries?

No, media queries are not a thing at the lexer stage. The media query grammar only comes in at a later stage.

> modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 185:
> 
>> 183:     @Test
>> 184:     void disjunctionAndConjunctionCanNotBeCombined() {
>> 185:         Stylesheet stylesheet = new CssParser().parse("""
> 
> could we also test for "or not" and "and not" ?

I've added a test.

> modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 295:
> 
>> 293: 
>> 294:     @Test
>> 295:     void parserRecoversWhenMediaQueryIsMalformed() {
> 
> should we also test malformed queries like `not not`, `and or` etc.?
> 
> also, unbalanced parentheses?

I've added a test for an invalid operator combination, as well as unbalanced parentheses.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074825549
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074825763
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826054
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826350
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826540
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826650
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826704
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074826935
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827009
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827074
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827147
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827215
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827296
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827385
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827444
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074827481
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074825633

From mstrauss at openjdk.org  Tue May  6 06:52:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 06:52:38 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <-XCS597GFog5Rg2dknGhN0xZDWRCHXy1Fa930HivAw8=.670e6355-2315-4d92-8d8f-5d9a191147f6@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <-XCS597GFog5Rg2dknGhN0xZDWRCHXy1Fa930HivAw8=.670e6355-2315-4d92-8d8f-5d9a191147f6@github.com>
Message-ID: <6dCCUPXontkNR9i9l0tP8AqttXQ785R_mLxVbW8tO9c=.1d75dadf-1506-425d-bfc1-55db6a06c7a4@github.com>

On Mon, 5 May 2025 18:11:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuerySerializer.java line 72:
>> 
>>> 70:                                    DataOutputStream os,
>>> 71:                                    StyleConverter.StringStore stringStore) throws IOException {
>>> 72:         os.writeByte(QueryType.of(mediaQuery).ordinal());
>> 
>> potential problem:
>> someone may insert/reorder QueryType enums and break backward compatibility.
>> at a minimum, a warning comment should be added to QueryType, or perhaps some more reliable code in read/writeBinary?
>
> or perhaps use hard-coded values instead 'c', 'f', 'C', 'd', 'n' ?

I've added an explicit `serializedId` value.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074825706

From mstrauss at openjdk.org  Tue May  6 06:56:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 06:56:21 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <oqI2pikgqFnR45CWiX7YbTVjcx2UZMg9RTxscKfF4QY=.1fd0030d-9cab-4dc8-8c7c-21541b1defe5@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <oqI2pikgqFnR45CWiX7YbTVjcx2UZMg9RTxscKfF4QY=.1fd0030d-9cab-4dc8-8c7c-21541b1defe5@github.com>
Message-ID: <1qzqJYioufdV8NudaoSmBMeMSkohhTxTaGKcGX6gX9g=.1c9fb6c5-b10c-47eb-a2cb-596a01860aa7@github.com>

On Mon, 5 May 2025 20:44:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Should this work?

No. I've added a test for it.

> Also, are people supposed to know what LPAREN is? Can we provide more user friendly error messages?

The error messages of `CssParser` are what they are, I guess. For example, it will also emit messages like "Expected LBRACE" and "Expected RBRACE". If we change that, then probably with a cleanup ticket.

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

PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2853464109

From mstrauss at openjdk.org  Tue May  6 07:05:31 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 07:05:31 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
Message-ID: <L9umdeQfuERjA2h3RW8RvYtstZ8LIAC9l9TbwN1CTl0=.2116f3f4-4d83-4904-ae77-e147e47ddb7b@github.com>

On Mon, 5 May 2025 15:11:47 GMT, Andy Goryachev <angorya 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 30 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - cssref doc
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/media-query.svg line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
>> 2: <svg
> 
> just an observation: these images look blurry on my mac external monitor (scale=1) relative to the w3.org ones (on the left):
> 
> ![Screenshot 2025-05-05 at 08 06 36](https://github.com/user-attachments/assets/8ba6fe7b-ec1c-4297-b6ce-0796a314e9aa)

I don't really see a major difference on your screenshot, both versions look blurry to me. When I open `cssref.html` in Chrome, it looks quite sharp.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074845490

From mstrauss at openjdk.org  Tue May  6 07:10:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 07:10:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
Message-ID: <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>

On Fri, 2 May 2025 23:06:55 GMT, Andy Goryachev <angorya 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 28 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - improved implementation of NullCoalescingPropertyBase
>>  - small refactor
>>  - ... and 18 more: https://git.openjdk.org/jfx/compare/3fdd2138...32abb8a3
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 871:
> 
>> 869:             <code>(prefers-color-scheme: dark) and (prefers-reduced-motion) or (prefers-reduced-transparency)</code>
>> 870:             is illegal, as it is unclear what was meant. In this case, parentheses must be used to group expressions.
>> 871:     </ul>
> 
> maybe one or two examples would be helpful here.

I don't want to overload cssref with too many examples, as this is not supposed to be a general-purpose CSS documentation. The media query doc is already quite comprehensive as it is. For detailed information, there's always the W3C specification, and hundreds of third-party sources.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074850421

From mstrauss at openjdk.org  Tue May  6 07:37:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 07:37:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@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:

  improve synchronization in PreferenceProperties

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/0848e6b7..035a1b03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=22
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=21-22

  Stats: 64 lines in 1 file changed: 26 ins; 13 del; 25 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 May  6 07:37:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 07:37:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
Message-ID: <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>

On Mon, 5 May 2025 15:17:32 GMT, Andy Goryachev <angorya 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 30 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - cssref doc
>>  - Merge branch 'master' into feature/media-queries
>>  - reorder fields
>>  - remove ReadOnlyBooleanWrapper
>>  - Scene preferences only actively observe platform preferences when the scene is showing
>>  - formatting
>>  - typo
>>  - use equality instead of identity
>>  - rename TokenStream methods
>>  - ... and 20 more: https://git.openjdk.org/jfx/compare/498b7e4c...626a904d
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 184:
> 
>> 182: 
>> 183:             for (DeferredProperty<?> property : deferredProperties.values()) {
>> 184:                 property.fireValueChangedIfNecessary();
> 
> firing events from a synchronized method is a recipe for a lockup.
> JavaFX is still a single threaded toolkit (if we ignore the creation of certain objects aspect), why do we want to synchronize?

I've moved the `fireValueChangedIfNecessary` out of the synchronized block. We need the synchronized block as a memory barrier to see the latest value of the `effectiveValue` field, as we need to be able to read it from any thread.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2074888025

From arapte at openjdk.org  Tue May  6 10:33:20 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 6 May 2025 10:33:20 GMT
Subject: RFR: 8354875: Update to GCC 14.2.0 on Linux
In-Reply-To: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
References: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
Message-ID: <kPEwcqkHinrCkYnh9SX_Orbpj1XR5SX_4BOh_9GcyjQ=.ca303451-2650-4b75-8688-8a84f37a48fe@github.com>

On Thu, 17 Apr 2025 18:17:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Linux to GCC 14.2.0 (from 13.2.0) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit, on the following:
> 
> * [x] Oracle Linux 8 (our production build and headless test platform)
> * [x] Ubuntu 16.04
> * [x] Ubuntu 22.04
> * [x] Ubuntu 24.04

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1784#pullrequestreview-2817753289

From jhendrikx at openjdk.org  Tue May  6 10:41:26 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 6 May 2025 10:41:26 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <L9umdeQfuERjA2h3RW8RvYtstZ8LIAC9l9TbwN1CTl0=.2116f3f4-4d83-4904-ae77-e147e47ddb7b@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <L9umdeQfuERjA2h3RW8RvYtstZ8LIAC9l9TbwN1CTl0=.2116f3f4-4d83-4904-ae77-e147e47ddb7b@github.com>
Message-ID: <PbBhI4YvOAoL6C2TWb0tAiFLosuIfKnsDVEq7FXPBbo=.364ec448-c8a1-4a48-8b37-eb36f7e29846@github.com>

On Tue, 6 May 2025 07:03:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/media-query.svg line 2:
>> 
>>> 1: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
>>> 2: <svg
>> 
>> just an observation: these images look blurry on my mac external monitor (scale=1) relative to the w3.org ones (on the left):
>> 
>> ![Screenshot 2025-05-05 at 08 06 36](https://github.com/user-attachments/assets/8ba6fe7b-ec1c-4297-b6ce-0796a314e9aa)
>
> I don't really see a major difference on your screenshot, both versions look blurry to me. When I open `cssref.html` in Chrome, it looks quite sharp.

It looks sharp to me as well.  The w3.org one looks better when I view it on the actual website (not your snapshot above).  

Mac renders things slightly differently and leans heavily on anti-aliasing to represent visuals as accurately as possible; this works well on high-DPI displays but tends to look blurry on lower-DPI screens. Windows, on the other hand, limits anti-aliasing more to achieve a crisper, sharper result; this is more effective on lower-DPI displays and doesn't really make a difference for high-DPI screens.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075193668

From lkostyra at openjdk.org  Tue May  6 11:54:28 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 6 May 2025 11:54:28 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v16]
In-Reply-To: <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
Message-ID: <jjmcB5nQjBVXsX8DEOctB91OdqrxSQQ_gt2aDjJisL0=.74ea1688-1a2e-4b01-98f1-68f1643eca97@github.com>

On Mon, 5 May 2025 10:28:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestStage conflicting value listener

I still have to do some local testing and run your test apps, but in the meantime I left some minor comments. Overall looks good.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 364:

> 362: void WindowContext::notify_repaint() {
> 363:     if (jview) {
> 364: //        LOG0("jViewNotifyRepaint\n");

I would either uncomment this log or remove it

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 373:

> 371: void WindowContext::notify_repaint(GdkRectangle *rect) {
> 372:     if (jview) {
> 373: //        LOG4("jViewNotifyRepaint %d, %d, %d, %d\n", rect->x, rect->y, rect->width, rect->height);

As above

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h line 142:

> 140:     gint initial_state_mask;
> 141: protected:
> 142: protected:

`protected:` is doubled here, you could remove one of those

tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Copyright should be `2024, 2025,` when you're updating an older file

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-2811440726
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075244728
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075245842
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075273226
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075297374

From lkostyra at openjdk.org  Tue May  6 11:54:30 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 6 May 2025 11:54:30 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v12]
In-Reply-To: <kkVlWiXINArtaFkv_7u6Ufi0gvpVHDJfEwMhG-2t94o=.3d61d69a-4fc7-455f-b9ff-dbca35040993@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <kkVlWiXINArtaFkv_7u6Ufi0gvpVHDJfEwMhG-2t94o=.3d61d69a-4fc7-455f-b9ff-dbca35040993@github.com>
Message-ID: <VquoQezl9JWwJ4LBrQMX5O9_DeapUUHLJUsjuTCtV6E=.cbed5064-43ad-4cb8-a82d-5d02da22d93a@github.com>

On Thu, 1 May 2025 14:50:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test on SizingTest

modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 486:

> 484:                 case GDK_PROPERTY_NOTIFY:
> 485:                     ctx->process_property_notify(&event->property);
> 486:                     gtk_main_do_event(event);

Some event types first call respective `ctx->process` and then `gtk_main_do_event`, while others do it the other way around. Is there a specific reason why?

modules/javafx.graphics/src/main/native-glass/gtk/GlassRobot.cpp line 22:

> 20:  *
> 21:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> 22:  * or visit www.oracle.com if you need additiFonal information or have any

Coincidental change in copyright header

modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h line 251:

> 249: #define LOG5(msg, param1, param2, param3, param4, param5) {printf(msg, param1, param2, param3, param4, param5);fflush(stdout);}
> 250: #define LOG6(msg, param1, param2, param3, param4, param5, param6) {printf(msg, param1, param2, param3, param4, param5, param6);fflush(stdout);}
> 251: #define LOG10(msg, param1, param2, param3, param4, param5, param6, param7, param8, param9, param10) \

Instead of adding more `LOG*` macros consider replacing them with `#define LOG(...) { printf(__VA_ARGS__); fflush(stdout); }`

Eventually I would accept filing a separate change for improving this if we don't have one already. Seems like the `ERROR` macros below could also be improved in this way.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071271567
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071440205
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071479393

From tsayao at openjdk.org  Tue May  6 12:26:23 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 May 2025 12:26:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v16]
In-Reply-To: <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
Message-ID: <c6L7IlB_H3bvNeKyzb4Q7uAbwDjwp--kb7AgOX-H_EE=.7725335b-5f3f-484d-9dd9-c2e6d9a6e222@github.com>

On Mon, 5 May 2025 10:28:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestStage conflicting value listener

There is a test that is failing on `StageOwnershipTest` due to the focus stealing prevention mechanism that exists on gnome that I need to address.

Other than that, all tests pass on Ubuntu 24.04 on Xwayland and Xorg.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2854382668

From kcr at openjdk.org  Tue May  6 13:03:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 May 2025 13:03:20 GMT
Subject: Integrated: 8354875: Update to GCC 14.2.0 on Linux
In-Reply-To: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
References: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
Message-ID: <4_K-TCpGxvtnrGkYjaWC8xjYL8L0zauCVoCKfcijtHY=.7d00dd8b-ae45-47d5-8a9b-583f45812714@github.com>

On Thu, 17 Apr 2025 18:17:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Linux to GCC 14.2.0 (from 13.2.0) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit, on the following:
> 
> * [x] Oracle Linux 8 (our production build and headless test platform)
> * [x] Ubuntu 16.04
> * [x] Ubuntu 22.04
> * [x] Ubuntu 24.04

This pull request has now been integrated.

Changeset: efaff94e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/efaff94e3dc39f23235eaaff3cc95211abc8827b
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8354875: Update to GCC 14.2.0 on Linux

Reviewed-by: sykora, arapte

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

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

From tsayao at openjdk.org  Tue May  6 13:10:03 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 May 2025 13:10:03 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v17]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <MFMeNcj4rcJg8lr50UlEJ-4XssOj11LIJHgyG7e-uEU=.4e175deb-2346-4e6d-a47b-5c249141a9e6@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/f116775b..3e9a66d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=15-16

  Stats: 61 lines in 6 files changed: 2 ins; 9 del; 50 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Tue May  6 13:10:04 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 May 2025 13:10:04 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v12]
In-Reply-To: <VquoQezl9JWwJ4LBrQMX5O9_DeapUUHLJUsjuTCtV6E=.cbed5064-43ad-4cb8-a82d-5d02da22d93a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <kkVlWiXINArtaFkv_7u6Ufi0gvpVHDJfEwMhG-2t94o=.3d61d69a-4fc7-455f-b9ff-dbca35040993@github.com>
 <VquoQezl9JWwJ4LBrQMX5O9_DeapUUHLJUsjuTCtV6E=.cbed5064-43ad-4cb8-a82d-5d02da22d93a@github.com>
Message-ID: <ceDGr2V6xSzXQNqva21PS_bbT-iCIJnz3nUaGb8Slfo=.5a539c92-c7a5-4c3e-aa76-a25eed4bfb8c@github.com>

On Fri, 2 May 2025 08:22:18 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test on SizingTest
>
> modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 486:
> 
>> 484:                 case GDK_PROPERTY_NOTIFY:
>> 485:                     ctx->process_property_notify(&event->property);
>> 486:                     gtk_main_do_event(event);
> 
> Some event types first call respective `ctx->process` and then `gtk_main_do_event`, while others do it the other way around. Is there a specific reason why?

Yes, Gtk updates the window state (maximized, fullscreen, iconified) values that are used after on the `process_configure` and `process_state`. I added a comment.

> modules/javafx.graphics/src/main/native-glass/gtk/GlassRobot.cpp line 22:
> 
>> 20:  *
>> 21:  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> 22:  * or visit www.oracle.com if you need additiFonal information or have any
> 
> Coincidental change in copyright header

Fixed

> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h line 251:
> 
>> 249: #define LOG5(msg, param1, param2, param3, param4, param5) {printf(msg, param1, param2, param3, param4, param5);fflush(stdout);}
>> 250: #define LOG6(msg, param1, param2, param3, param4, param5, param6) {printf(msg, param1, param2, param3, param4, param5, param6);fflush(stdout);}
>> 251: #define LOG10(msg, param1, param2, param3, param4, param5, param6, param7, param8, param9, param10) \
> 
> Instead of adding more `LOG*` macros consider replacing them with `#define LOG(...) { printf(__VA_ARGS__); fflush(stdout); }`
> 
> Eventually I would accept filing a separate change for improving this if we don't have one already. Seems like the `ERROR` macros below could also be improved in this way.

Nice tip, thanks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075438459
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075440319
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075438879

From tsayao at openjdk.org  Tue May  6 13:10:05 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 May 2025 13:10:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v16]
In-Reply-To: <jjmcB5nQjBVXsX8DEOctB91OdqrxSQQ_gt2aDjJisL0=.74ea1688-1a2e-4b01-98f1-68f1643eca97@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
 <jjmcB5nQjBVXsX8DEOctB91OdqrxSQQ_gt2aDjJisL0=.74ea1688-1a2e-4b01-98f1-68f1643eca97@github.com>
Message-ID: <4Vzmz8eaeM_EI2a8RPmfzlWBDJ1ZH1VbM3p7rneCnkM=.00bece09-019c-4790-8434-ed1ea9efa6eb@github.com>

On Tue, 6 May 2025 11:14:05 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix TestStage conflicting value listener
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 364:
> 
>> 362: void WindowContext::notify_repaint() {
>> 363:     if (jview) {
>> 364: //        LOG0("jViewNotifyRepaint\n");
> 
> I would either uncomment this log or remove it

Done

> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 373:
> 
>> 371: void WindowContext::notify_repaint(GdkRectangle *rect) {
>> 372:     if (jview) {
>> 373: //        LOG4("jViewNotifyRepaint %d, %d, %d, %d\n", rect->x, rect->y, rect->width, rect->height);
> 
> As above

Done

> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h line 142:
> 
>> 140:     gint initial_state_mask;
>> 141: protected:
>> 142: protected:
> 
> `protected:` is doubled here, you could remove one of those

Fixed

> tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright should be `2024, 2025,` when you're updating an older file

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075439188
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075439387
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075439688
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2075439889

From angorya at openjdk.org  Tue May  6 14:55:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 14:55:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
Message-ID: <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>

On Tue, 6 May 2025 07:33:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 184:
>> 
>>> 182: 
>>> 183:             for (DeferredProperty<?> property : deferredProperties.values()) {
>>> 184:                 property.fireValueChangedIfNecessary();
>> 
>> firing events from a synchronized method is a recipe for a lockup.
>> JavaFX is still a single threaded toolkit (if we ignore the creation of certain objects aspect), why do we want to synchronize?
>
> I've moved the `fireValueChangedIfNecessary` out of the synchronized block. We need the synchronized block as a memory barrier to see the latest value of the `effectiveValue` field, as we need to be able to read it from any thread.

Maybe a `volatile` would be a better choice then?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075657221

From angorya at openjdk.org  Tue May  6 15:48:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 15:48:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
 <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
Message-ID: <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>

On Tue, 6 May 2025 07:07:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 871:
>> 
>>> 869:             <code>(prefers-color-scheme: dark) and (prefers-reduced-motion) or (prefers-reduced-transparency)</code>
>>> 870:             is illegal, as it is unclear what was meant. In this case, parentheses must be used to group expressions.
>>> 871:     </ul>
>> 
>> maybe one or two examples would be helpful here.
>
> I don't want to overload cssref with too many examples, as this is not supposed to be a general-purpose CSS documentation. The media query doc is already quite comprehensive as it is. For detailed information, there's always the W3C specification, and hundreds of third-party sources.

I insist: the doc should include an example with an operator, and possibly how to achieve A and not B case mentioned earlier.

Assume the reader has no clue how media queries work and does not want to wade through the massive and unrelated w3.org spec.  The `cssref.html` should be self-sufficient in that sense, in my opinion.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075729576

From angorya at openjdk.org  Tue May  6 15:48:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 15:48:28 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
Message-ID: <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>

On Tue, 6 May 2025 06:47:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/expression/FunctionExpression.java line 66:
>> 
>>> 64:     @Override
>>> 65:     public int hashCode() {
>>> 66:         return Objects.hash(featureName, featureValue, value);
>> 
>> very minor: maybe add `FunctionExpression.class` to the mix?
>
> Why?

so an array with the same values produces a different hash code.
in reality, it's highly unlikely.

However, `FunctionExpression` is a `record`.  What's the point of declaring it a record when you override `hashCode` and `equals`?

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssLexer.java line 34:
>> 
>>> 32: 
>>> 33: public final class CssLexer {
>>> 34:     public final static int STRING = 10;
>> 
>> minor: `public static final` maybe?
>
> I want to keep the diffs minimal here, because I didn't change anything except making the constants public.

the github diff shows it as completely different block anyway, so without copypasting to BeyondCompary I could not see it.
Might as well change to canonical ordering, no?

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/TokenStream.java line 73:
>> 
>>> 71:     }
>>> 72: 
>>> 73:     public void reconsume() {
>> 
>> maybe a javadoc would suffice if you like the name so much
>
> I've added javadocs to all methods. By the way, I don't really get the opposition to the name. The arguments presented so far do not convince me to drop CSS lingo.

people who are not experts with web css are confused.
anyway, I am ok with it - as long as it's documented.
thanks!

>> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/parser/CssLexerTest.java line 47:
>> 
>>> 45:     }
>>> 46: 
>>> 47:     private void checkTokens(List<Token> resultTokens, Token... expectedTokens) {
>> 
>> should there be new tests in `CssLexerTest` for the `@media` queries?
>
> No, media queries are not a thing at the lexer stage. The media query grammar only comes in at a later stage.

oh, the handling of the `@media` tokens is done at a different level?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075748289
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075750493
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075695509
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075755099

From angorya at openjdk.org  Tue May  6 15:48:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 15:48:24 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
Message-ID: <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>

On Tue, 6 May 2025 07:37: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:
> 
>   improve synchronization in PreferenceProperties

Thank you for making changes and adding tests!  And sorry for all the nitpicking.

Looks good, with only two sticky points remaining:

- I would like to see an example of correct syntax for the operator (and/or how to write `and not` case)
- still think synchronization should not be used, instead use `volatile` and check for fx thread in the mutators.

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 228:

> 226:         public T get() {
> 227:             // We need to synchronized on 'mutex' to see 'effectiveValue', because get() may be called
> 228:             // on a thread other than the FX application thread.

use `volatile` instead of synchronization?

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 258:

> 256:         }
> 257: 
> 258:         // This method must only be called on the FX application thread.

add `Toolkit.getToolkit().checkFxUserThread();` then?

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 312:

> 310: 
> 311:         // This method must only be called when synchronized on 'mutex'.
> 312:         public void updateEffectiveValue() {

maybe make this method private then: the instance of this class is available via `Platform.getPreferences()` if I read this correctly

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 324:

> 322: 
> 323:         // This method must only be called on the FX application thread.
> 324:         public void fireValueChangeIfNecessary() {

same here: make the method `private`.

modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 316:

> 314:     void invalidCombinationOfConjunctionAndNegationEvaluatesToFalse() {
> 315:         Stylesheet stylesheet = new CssParser().parse("""
> 316:             @media (prefers-reduced-motion: reduce) and not (prefers-color-scheme: dark) {

for my education, how can one express this logic?
i.e. `prefers A and not B` ?

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2818605375
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075664290
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075663501
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075688616
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075689325
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075698899

From angorya at openjdk.org  Tue May  6 15:48:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 15:48:26 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <PbBhI4YvOAoL6C2TWb0tAiFLosuIfKnsDVEq7FXPBbo=.364ec448-c8a1-4a48-8b37-eb36f7e29846@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <L9umdeQfuERjA2h3RW8RvYtstZ8LIAC9l9TbwN1CTl0=.2116f3f4-4d83-4904-ae77-e147e47ddb7b@github.com>
 <PbBhI4YvOAoL6C2TWb0tAiFLosuIfKnsDVEq7FXPBbo=.364ec448-c8a1-4a48-8b37-eb36f7e29846@github.com>
Message-ID: <fsox-CZcLlUepc6GjrjeKEuU5_tnA0ieXAVp9Ej07fU=.ba5a6325-7409-451a-ab98-d1dc7abef5a2@github.com>

On Tue, 6 May 2025 10:38:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I don't really see a major difference on your screenshot, both versions look blurry to me. When I open `cssref.html` in Chrome, it looks quite sharp.
>
> It looks sharp to me as well.  The w3.org one looks better when I view it on the actual website (not your snapshot above).  
> 
> Mac renders things slightly differently and leans heavily on anti-aliasing to represent visuals as accurately as possible; this works well on high-DPI displays but tends to look blurry on lower-DPI screens. Windows, on the other hand, limits anti-aliasing more to achieve a crisper, sharper result; this is more effective on lower-DPI displays and doesn't really make a difference for high-DPI screens.

it's ok, just wanted to share an observation.  it looks ok on the primary retina screen, it's the external monitor at scale 1.0 where your svgs look blurry but w3.org do not.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075736557

From angorya at openjdk.org  Tue May  6 15:58:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 15:58:24 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
 <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
Message-ID: <tjkMbxOpgW_cj6m7KYrTdm8XllV-WPC0VkYKoByQEUg=.2d987b2d-1d1e-41fe-ba30-fdc9432ec73b@github.com>

On Tue, 6 May 2025 15:37:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Why?
>
> so an array with the same values produces a different hash code.
> in reality, it's highly unlikely.
> 
> However, `FunctionExpression` is a `record`.  What's the point of declaring it a record when you override `hashCode` and `equals`?

> Why?

made me think.  the reason is _probably_ so that `class B extends A` would produce a different `hashCode`, but then `A.hashCode` should include not the class instance, but the `getClass()`:


class A {
  public int hashCode() {
    return Objects.hash(getClass(), ...);
  }
}

class B extends A {
  // B.hashCode() produces a value different from A.hashCode()
}

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2075781903

From angorya at openjdk.org  Tue May  6 17:21:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 17:21:29 GMT
Subject: Withdrawn: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <JmxKPsaqV126GElLEkeQ9sa_Z3VYUy2KSriQRWVjaiU=.c182f9bb-ee50-4e3a-a05a-1a21e34fbfb6@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

This pull request has been closed without being integrated.

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

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

From mstrauss at openjdk.org  Tue May  6 18:48:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 18:48:21 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
Message-ID: <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>

On Tue, 6 May 2025 14:52:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I've moved the `fireValueChangedIfNecessary` out of the synchronized block. We need the synchronized block as a memory barrier to see the latest value of the `effectiveValue` field, as we need to be able to read it from any thread.
>
> Maybe a `volatile` would be a better choice then?

`volatile` is not enough, because the different values are correlated (for example `foreground`, `background`, and `colorScheme`). All values need to be updated in a single transaction, as otherwise we could end up reading a transient combination of values.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076061396

From angorya at openjdk.org  Tue May  6 18:54:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 18:54:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
Message-ID: <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>

On Tue, 6 May 2025 18:45:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Maybe a `volatile` would be a better choice then?
>
> `volatile` is not enough, because the different values are correlated (for example `foreground`, `background`, and `colorScheme`). All values need to be updated in a single transaction, as otherwise we could end up reading a transient combination of values.

I see.  The I suggest we enforce single-threaded nature of it: everything must happen in the FX Application Thread.  I don't think it's a good idea to start synchronizing things in FX now all of a sudden.

Any code that wants to access FX from a background thread must do so using a combination of `runLater` and a `CountDownLatch`.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076069191

From mstrauss at openjdk.org  Tue May  6 19:19:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 19:19:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
 <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
Message-ID: <aY5XiVwfdX7eDU8uid6tnPW_BB-8N5jX0XKlbihoVf0=.ce307916-679d-451a-83b6-bfe1b67ef0ba@github.com>

On Tue, 6 May 2025 15:40:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No, media queries are not a thing at the lexer stage. The media query grammar only comes in at a later stage.
>
> oh, the handling of the `@media` tokens is done at a different level?

`CssLexer` is responsible for converting the stylesheet text into a token stream. In this stream, `@media` appears as an `AT_KEYWORD` token, but no further syntactic processing is done (i.e. the parser doesn't care at all if the sequence of tokens makes any sense). This only happens in `CssParser`, where the actual value of the token is inspected and subsequent tokens are interpreted according to a specific grammar (in this case, the media query grammar). That's why all of the parsing tests are in `CssParser_mediaQuery_Test`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076095073

From mstrauss at openjdk.org  Tue May  6 19:19:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 19:19:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
Message-ID: <hGCOybkZfyJkFuqLXQJLJzd69tqLrlg8ZAGPpd3G2Pk=.e209d4b0-1d1b-4ef9-95bb-14287a8c468f@github.com>

On Tue, 6 May 2025 15:14:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve synchronization in PreferenceProperties
>
> modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 316:
> 
>> 314:     void invalidCombinationOfConjunctionAndNegationEvaluatesToFalse() {
>> 315:         Stylesheet stylesheet = new CssParser().parse("""
>> 316:             @media (prefers-reduced-motion: reduce) and not (prefers-color-scheme: dark) {
> 
> for my education, how can one express this logic?
> i.e. `prefers A and not B` ?

That would be `(prefers-A) and (not (prefers-B))`. A bit convoluted, but that's what the grammar says...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076097819

From angorya at openjdk.org  Tue May  6 19:19:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 19:19:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <hGCOybkZfyJkFuqLXQJLJzd69tqLrlg8ZAGPpd3G2Pk=.e209d4b0-1d1b-4ef9-95bb-14287a8c468f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <hGCOybkZfyJkFuqLXQJLJzd69tqLrlg8ZAGPpd3G2Pk=.e209d4b0-1d1b-4ef9-95bb-14287a8c468f@github.com>
Message-ID: <zsxb3OXy_F_9h-lc2z9-jHlwpa4Sdq5xItGwxN6LnZ4=.a4157236-80a3-45a0-9471-9e6a103bdda0@github.com>

On Tue, 6 May 2025 19:13:18 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java line 316:
>> 
>>> 314:     void invalidCombinationOfConjunctionAndNegationEvaluatesToFalse() {
>>> 315:         Stylesheet stylesheet = new CssParser().parse("""
>>> 316:             @media (prefers-reduced-motion: reduce) and not (prefers-color-scheme: dark) {
>> 
>> for my education, how can one express this logic?
>> i.e. `prefers A and not B` ?
>
> That would be `(prefers-A) and (not (prefers-B))`. A bit convoluted, but that's what the grammar says...

please add this example to `cssref.html`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076102352

From mstrauss at openjdk.org  Tue May  6 19:22:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 19:22:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
Message-ID: <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>

On Tue, 6 May 2025 18:51:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `volatile` is not enough, because the different values are correlated (for example `foreground`, `background`, and `colorScheme`). All values need to be updated in a single transaction, as otherwise we could end up reading a transient combination of values.
>
> I see.  The I suggest we enforce single-threaded nature of it: everything must happen in the FX Application Thread.  I don't think it's a good idea to start synchronizing things in FX now all of a sudden.
> 
> Any code that wants to access FX from a background thread must do so using a combination of `runLater` and a `CountDownLatch`.
> 
> What do you think?

That would be okay, except that `Scene` is allowed to be created on a background thread (it's in the class documentation), so we can't completely enforce it to be single-threaded. Once a scene is created, a user can also request its preferences. This is when we need some way to get the current platform preferences on a background thread, as otherwise users would potentially see the scene preferences suddenly change once the scene is shown.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076107914

From angorya at openjdk.org  Tue May  6 19:29:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 19:29:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
Message-ID: <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>

On Tue, 6 May 2025 19:20:04 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I see.  The I suggest we enforce single-threaded nature of it: everything must happen in the FX Application Thread.  I don't think it's a good idea to start synchronizing things in FX now all of a sudden.
>> 
>> Any code that wants to access FX from a background thread must do so using a combination of `runLater` and a `CountDownLatch`.
>> 
>> What do you think?
>
> That would be okay, except that `Scene` is allowed to be created on a background thread (it's in the class documentation), so we can't completely enforce it to be single-threaded. Once a scene is created, a user can also request its preferences. This is when we need some way to get the current platform preferences on a background thread, as otherwise users would potentially see the scene preferences suddenly change once the scene is shown.

That's why I am against this background thread nonsense.  Create - yes (even though I am against this).  Access and modify properties, especially those that interact with other parts of the FX - no.

I think we should enforce the FX application thread access.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076116995

From mstrauss at openjdk.org  Tue May  6 20:23:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:23:01 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
 <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
 <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>
Message-ID: <UcMG_9OPwuGq-IO53UceZ1Fi_8C46A1DgfecAQDSfVA=.55ca3b64-66e5-49cb-bf9a-025cff688780@github.com>

On Tue, 6 May 2025 15:26:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I don't want to overload cssref with too many examples, as this is not supposed to be a general-purpose CSS documentation. The media query doc is already quite comprehensive as it is. For detailed information, there's always the W3C specification, and hundreds of third-party sources.
>
> I insist: the doc should include an example with an operator, and possibly how to achieve A and not B case mentioned earlier.
> 
> Assume the reader has no clue how media queries work and does not want to wade through the massive and unrelated w3.org spec.  The `cssref.html` should be self-sufficient in that sense, in my opinion.

I've added more examples to cssref.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076216906

From mstrauss at openjdk.org  Tue May  6 20:23:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:23:01 GMT
Subject: RFR: 8345348: CSS media feature queries [v24]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <eBU3qiHE9lD5hAo2dsQG4ynoJIXKXb5W2IQCteBu7hc=.c2c91326-7aa9-4a32-8017-e93d65fe8f7c@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:

 - cssref documentation changes
 - added test
 - canonical modifier order

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/035a1b03..24354dd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=22-23

  Stats: 84 lines in 3 files changed: 41 ins; 0 del; 43 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 May  6 20:23:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:23:02 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
 <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
Message-ID: <RIeT5AyX0ef4loXwD_CccKzdwAxvzbxIAx2Pb7bfbc8=.8aa736a2-7b1c-400b-817f-51dc85cd91d3@github.com>

On Tue, 6 May 2025 15:38:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I want to keep the diffs minimal here, because I didn't change anything except making the constants public.
>
> the github diff shows it as completely different block anyway, so without copypasting to BeyondCompary I could not see it.
> Might as well change to canonical ordering, no?

Changed to canonical modifier order.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076218866

From angorya at openjdk.org  Tue May  6 20:26:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 20:26:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <UcMG_9OPwuGq-IO53UceZ1Fi_8C46A1DgfecAQDSfVA=.55ca3b64-66e5-49cb-bf9a-025cff688780@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
 <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
 <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>
 <UcMG_9OPwuGq-IO53UceZ1Fi_8C46A1DgfecAQDSfVA=.55ca3b64-66e5-49cb-bf9a-025cff688780@github.com>
Message-ID: <700db2-dddNCRtG_FmmY1Y8nYM_3F2P8y1hpBfNjKtI=.9b618cc8-a0f5-43ab-aa0d-c58cba60c0eb@github.com>

On Tue, 6 May 2025 20:18:05 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I insist: the doc should include an example with an operator, and possibly how to achieve A and not B case mentioned earlier.
>> 
>> Assume the reader has no clue how media queries work and does not want to wade through the massive and unrelated w3.org spec.  The `cssref.html` should be self-sufficient in that sense, in my opinion.
>
> I've added more examples to cssref.

Thank you!

I might suggest to drop `<ul>` since these bullets are somewhat of a distraction.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076224365

From mstrauss at openjdk.org  Tue May  6 20:26:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:26:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
Message-ID: <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>

On Tue, 6 May 2025 19:26:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> That would be okay, except that `Scene` is allowed to be created on a background thread (it's in the class documentation), so we can't completely enforce it to be single-threaded. Once a scene is created, a user can also request its preferences. This is when we need some way to get the current platform preferences on a background thread, as otherwise users would potentially see the scene preferences suddenly change once the scene is shown.
>
> That's why I am against this background thread nonsense.  Create - yes (even though I am against this).  Access and modify properties, especially those that interact with other parts of the FX - no.
> 
> I think we should enforce the FX application thread access.

This would be a significant change, as currently `Scene` is explicitly allowed to be created _and modified_ on a background thread. This was probably always a very bad idea (because it makes the implementation so much more difficult), but how do you think we should change that?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076223572

From mstrauss at openjdk.org  Tue May  6 20:32:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:32:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <700db2-dddNCRtG_FmmY1Y8nYM_3F2P8y1hpBfNjKtI=.9b618cc8-a0f5-43ab-aa0d-c58cba60c0eb@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
 <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
 <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>
 <UcMG_9OPwuGq-IO53UceZ1Fi_8C46A1DgfecAQDSfVA=.55ca3b64-66e5-49cb-bf9a-025cff688780@github.com>
 <700db2-dddNCRtG_FmmY1Y8nYM_3F2P8y1hpBfNjKtI=.9b618cc8-a0f5-43ab-aa0d-c58cba60c0eb@github.com>
Message-ID: <x5fr6BSpC8Qp0FeOxES2d9jdIo3gcjmzJWE60-wnvZQ=.a76c998c-99ee-400c-a571-1ec9289070c9@github.com>

On Tue, 6 May 2025 20:23:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I've added more examples to cssref.
>
> Thank you!
> 
> I might suggest to drop `<ul>` since these bullets are somewhat of a distraction.

Without it, it just looks like a wall of text to me.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076232063

From angorya at openjdk.org  Tue May  6 20:32:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 20:32:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
Message-ID: <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-VuwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>

On Tue, 6 May 2025 20:23:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> That's why I am against this background thread nonsense.  Create - yes (even though I am against this).  Access and modify properties, especially those that interact with other parts of the FX - no.
>> 
>> I think we should enforce the FX application thread access.
>
> This would be a significant change, as currently `Scene` is explicitly allowed to be created _and modified_ on a background thread. This was probably always a very bad idea (because it makes the implementation so much more difficult), but how do you think we should change that?

how about: 

- the implementation must not fire any events before the Scene is shown
- the preferences getters should disallow calls from a background thread

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076229687

From angorya at openjdk.org  Tue May  6 20:36:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 20:36:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <x5fr6BSpC8Qp0FeOxES2d9jdIo3gcjmzJWE60-wnvZQ=.a76c998c-99ee-400c-a571-1ec9289070c9@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@github.com>
 <FtgSHz4W-R5jPD1DAHnRmjKxpcs408a61C-VLU1RzlU=.dae67ec8-5293-4933-be71-987bcbd8e34a@github.com>
 <xJE0_pjL2tmQwGaIo_kqqBbKu-1gg7CzxBZQtD7vFCE=.44668300-e0a7-4c41-b820-23250ef3a28d@github.com>
 <ehxUjADA0LDS_UdAGhgZ3i0FRunQa0tl5zAg4-hieZs=.b2d75220-73bd-4ae8-8e60-741fd4bc042f@github.com>
 <UcMG_9OPwuGq-IO53UceZ1Fi_8C46A1DgfecAQDSfVA=.55ca3b64-66e5-49cb-bf9a-025cff688780@github.com>
 <700db2-dddNCRtG_FmmY1Y8nYM_3F2P8y1hpBfNjKtI=.9b618cc8-a0f5-43ab-aa0d-c58cba60c0eb@github.com>
 <x5fr6BSpC8Qp0FeOxES2d9jdIo3gcjmzJWE60-wnvZQ=.a76c998c-99ee-400c-a571-1ec9289070c9@github.com>
Message-ID: <YXKUkTWBTEucMvXgMFPGx5HEdKyg7JpLI0SJzEydKuw=.c613577d-1bf4-4425-b694-2a32da157179@github.com>

On Tue, 6 May 2025 20:29:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Thank you!
>> 
>> I might suggest to drop `<ul>` since these bullets are somewhat of a distraction.
>
> Without it, it just looks like a wall of text to me.

ok

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076239222

From mstrauss at openjdk.org  Tue May  6 20:36:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 May 2025 20:36:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-VuwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
Message-ID: <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>

On Tue, 6 May 2025 20:27:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This would be a significant change, as currently `Scene` is explicitly allowed to be created _and modified_ on a background thread. This was probably always a very bad idea (because it makes the implementation so much more difficult), but how do you think we should change that?
>
> how about: 
> 
> - the implementation must not fire any events before the Scene is shown
> - the preferences getters should disallow calls from a background thread

1. That's how it is implemented. No change events before the scene is shown (only initial values are read).
2. Now this would be a direct contradiction of the specification, which would make the user model much harder. Suddenly the "you can create and modify a scene on a background thread" becomes "you can do that, but for this particular API, you can't". Since we're doing all of this mainly for application developers, the user model must be the first consideration.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076239473

From angorya at openjdk.org  Tue May  6 21:06:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 21:06:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
 <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
Message-ID: <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>

On Tue, 6 May 2025 20:33:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> how about: 
>> 
>> - the implementation must not fire any events before the Scene is shown
>> - the preferences getters should disallow calls from a background thread
>
> 1. That's how it is implemented. No change events before the scene is shown (only initial values are read).
> 2. Now this would be a direct contradiction of the specification, which would make the user model much harder. Suddenly the "you can create and modify a scene on a background thread" becomes "you can do that, but for this particular API, you can't". Since we're doing all of this mainly for application developers, the user model must be the first consideration.

PlatformPreferences.update() seems to be called only from the fx thread, if I read the code right.  What happens when the Scene is created in a bg thread and a listener added to its preferences, and an event is fired?  Will the statement `#1` be still valid?  (I don't see any code that delays the dispatch until after the Scene is shown).

`#2` - all this is good, but we seem to hand the gun to user and say: here, shoot yourself in the foot.  And they do.  I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it, so who am I to say otherwise?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2076275238

From angorya at openjdk.org  Tue May  6 21:16:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 May 2025 21:16:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v24]
In-Reply-To: <eBU3qiHE9lD5hAo2dsQG4ynoJIXKXb5W2IQCteBu7hc=.c2c91326-7aa9-4a32-8017-e93d65fe8f7c@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <eBU3qiHE9lD5hAo2dsQG4ynoJIXKXb5W2IQCteBu7hc=.c2c91326-7aa9-4a32-8017-e93d65fe8f7c@github.com>
Message-ID: <3fak4Lh-g0hFJREz3CWRvDaWs19vFjZhtANSjortkBc=.390a0e9b-e9aa-44f6-a375-77b3cb2bc802@github.com>

On Tue, 6 May 2025 20:23:01 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 three additional commits since the last revision:
> 
>  - cssref documentation changes
>  - added test
>  - canonical modifier order

Thank you for expanding CSS media query examples!  Verified that they work as expected:


@media (prefers-color-scheme: dark) and (not (prefers-persistent-scrollbars)) {
  .root {
    -fx-accent: yellow;
  }
}


I am still convinced javaFX should have been a single-threaded framework with no exceptions, but the current code seems ok as long as it's not abused.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2819661773

From kcr at openjdk.org  Tue May  6 21:35:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 May 2025 21:35:20 GMT
Subject: RFR: 8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <nTe_aCG_02hiUxapTN-j22Fso2GFEs4Lq0TTyu045fU=.65b69e86-cf1f-4c57-ba67-f7032aad306e@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

I verified that, in connection with the AWT fix, this fix allows the AWT OpenURIHandler to receive events when JavaFX is the primary toolkit.

I also verified that in the case where AWT is the primary toolkit, the code in question isn't ever called. So that mode works equally well with or without this fix.

I left a comment with a requested change, both to the name of the custom embedded event, and a request that it be defined as a static constant (put it near the top of the file).

modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 486:

> 484: 
> 485:         [[NSNotificationCenter defaultCenter]
> 486:                 postNotificationName:@"EmbeddedEvent"

I left a related comment in the AWT fix: `EmbeddedEvent` is too generic a name. I recommend two things:

1. Prefix it with `AWT`, so it would become `AWTEmbeddedEvent`
2. Create a static NSString constant for this string with a comment that this will allow JavaFX to send an event to AWT when AWT is embedded. Note in this comment that the name must match the name used by AWT. Put this string near the top of the file, perhaps after the `runLoopModes` constant.

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

PR Review: https://git.openjdk.org/jfx/pull/1755#pullrequestreview-2819606151
PR Review Comment: https://git.openjdk.org/jfx/pull/1755#discussion_r2076259111

From kcr at openjdk.org  Tue May  6 21:48:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 May 2025 21:48:21 GMT
Subject: RFR: 8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <9MiXmoNfjVBw00WcyQcRg6pnLySpIM-HuLGHsy7z7sA=.529ca30e-1407-4375-b723-dac5ff315304@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

I updated the JBS title slightly for (I hope) better clarity. Please update the PR title to match.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2856147406

From lkostyra at openjdk.org  Wed May  7 06:18:23 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 7 May 2025 06:18:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v17]
In-Reply-To: <MFMeNcj4rcJg8lr50UlEJ-4XssOj11LIJHgyG7e-uEU=.4e175deb-2346-4e6d-a47b-5c249141a9e6@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <MFMeNcj4rcJg8lr50UlEJ-4XssOj11LIJHgyG7e-uEU=.4e175deb-2346-4e6d-a47b-5c249141a9e6@github.com>
Message-ID: <70mBxpewfMqUaHG3BbAI5fWWGqPgOgd7Z9WiBMRNdV4=.4174a3dc-179e-42f1-afe3-5f09568e4b8e@github.com>

On Tue, 6 May 2025 13:10:03 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Found one extra issue that breaks build on Release

modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h line 244:

> 242: 
> 243: #ifdef VERBOSE
> 244: #define LOG(msg, ...) { printf(msg, ##__VA_ARGS__); fflush(stdout); }

This needs its empty/noop variant in the #else block as well, otherwise build will break on Release

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-2820454926
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2076858564

From mstrauss at openjdk.org  Wed May  7 09:18:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 May 2025 09:18:24 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
 <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
 <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>
Message-ID: <IfUQP_hYPJaPum89UjvidPXwDqJAsrI4hwuOHDip4tE=.4e7c34da-a859-4956-8f8f-0e91baef4fcb@github.com>

On Tue, 6 May 2025 21:03:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 1. That's how it is implemented. No change events before the scene is shown (only initial values are read).
>> 2. Now this would be a direct contradiction of the specification, which would make the user model much harder. Suddenly the "you can create and modify a scene on a background thread" becomes "you can do that, but for this particular API, you can't". Since we're doing all of this mainly for application developers, the user model must be the first consideration.
>
> PlatformPreferences.update() seems to be called only from the fx thread, if I read the code right.  What happens when the Scene is created in a bg thread and a listener added to its preferences, and an event is fired?  Will the statement `#1` be still valid?  (I don't see any code that delays the dispatch until after the Scene is shown).
> 
> `#2` - all this is good, but we seem to hand the gun to user and say: here, shoot yourself in the foot.  And they do.  I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it, so who am I to say otherwise?

`NullCoalescingPropertyBase` (used in `ScenePreferences`) is initially disconnected. It will set its initial value to the value is reads from `PlatformPreferences`, but it will not subscribe to change notifications. The reason for this is to prevent a scene that is created on a background thread from immediately receiving change notifications on the FX thread, which could not only potentially corrupt the property state (because they're not concurrently thread-safe), but also mess up the application state.

When the scene is shown, `NullCoalescingPropertyBase` will subscribe to change notifications from `PlatformPreferences`, because now we're safely on the FX thread. The code for that is in ScenePreferences:L142.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077196617

From mstrauss at openjdk.org  Wed May  7 09:24:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 May 2025 09:24:23 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <tjkMbxOpgW_cj6m7KYrTdm8XllV-WPC0VkYKoByQEUg=.2d987b2d-1d1e-41fe-ba30-fdc9432ec73b@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <Eun9dB6Ceo1ZGUkRKpZjQhakZKlKSjD9667FxBpQWos=.b1668ab1-23a2-4744-9097-77877c65793c@github.com>
 <vXD42-bqYVvzkKlOBea4Wwenl3ydJtNyapcQXgkDrng=.c3fd81ad-f47b-43b9-9a86-74da02c627e9@github.com>
 <tjkMbxOpgW_cj6m7KYrTdm8XllV-WPC0VkYKoByQEUg=.2d987b2d-1d1e-41fe-ba30-fdc9432ec73b@github.com>
Message-ID: <8_Dqg21gzkLTvIGlKnbgIZ7o2k5DaDJa2Qc59jwd3O8=.3201a0cb-f18d-418a-86ce-3178a87d8183@github.com>

On Tue, 6 May 2025 15:55:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> so an array with the same values produces a different hash code.
>> in reality, it's highly unlikely.
>> 
>> However, `FunctionExpression` is a `record`.  What's the point of declaring it a record when you override `hashCode` and `equals`?
>
>> Why?
> 
> made me think.  the reason is _probably_ so that `class B extends A` would produce a different `hashCode`, but then `A.hashCode` should include not the class instance, but the `getClass()`:
> 
> 
> class A {
>   public int hashCode() {
>     return Objects.hash(getClass(), ...);
>   }
> }
> 
> class B extends A {
>   // B.hashCode() produces a value different from A.hashCode()
> }

> so an array with the same values produces a different hash code. in reality, it's highly unlikely.
> 
> However, `FunctionExpression` is a `record`. What's the point of declaring it a record when you override `hashCode` and `equals`?

Mainly to get the shorter syntax, finality, and immutability. It really doesn't make any sense to use method references in determining object equality, as they could be different even when the same method is referenced.

I'm using object equality for query expressions in tests, as it allows me to easily verify the shape of the expression tree, so there is value in doing that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077206803

From mstrauss at openjdk.org  Wed May  7 09:28:30 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 May 2025 09:28:30 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
Message-ID: <OLZuF4qUWgF5SRf-ocKlbfcd0Jo61IsNnaRqOeK1-Dw=.8cfccd2d-0dc1-479b-bda8-8f08f8171082@github.com>

On Tue, 6 May 2025 15:08:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve synchronization in PreferenceProperties
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 312:
> 
>> 310: 
>> 311:         // This method must only be called when synchronized on 'mutex'.
>> 312:         public void updateEffectiveValue() {
> 
> maybe make this method private then: the instance of this class is available via `Platform.getPreferences()` if I read this correctly

No, the instance of `PreferenceProperties` only stored as a private field in `PlatformPreferences`. I'm usually using public methods in nested classes to indicate that the method is supposed to be called from outside of the nested class. That's not strictly necessary, but I think it serves to differentiate them from "purely" private methods.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077215278

From tsayao at openjdk.org  Wed May  7 09:30:05 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 09:30:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is realized. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not ...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix non-debug build

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/3e9a66d8..98eae77d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=16-17

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

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

From tsayao at openjdk.org  Wed May  7 09:30:06 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 09:30:06 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v17]
In-Reply-To: <70mBxpewfMqUaHG3BbAI5fWWGqPgOgd7Z9WiBMRNdV4=.4174a3dc-179e-42f1-afe3-5f09568e4b8e@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <MFMeNcj4rcJg8lr50UlEJ-4XssOj11LIJHgyG7e-uEU=.4e175deb-2346-4e6d-a47b-5c249141a9e6@github.com>
 <70mBxpewfMqUaHG3BbAI5fWWGqPgOgd7Z9WiBMRNdV4=.4174a3dc-179e-42f1-afe3-5f09568e4b8e@github.com>
Message-ID: <CdQs2oEgnaliVWoyCMpOacaTe1a4Rl5cfGkPYKpi9mU=.7c5f6cf4-4113-45e9-8556-b1ccabb255d3@github.com>

On Wed, 7 May 2025 06:08:46 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h line 244:
> 
>> 242: 
>> 243: #ifdef VERBOSE
>> 244: #define LOG(msg, ...) { printf(msg, ##__VA_ARGS__); fflush(stdout); }
> 
> This needs its empty/noop variant in the #else block as well, otherwise build will break on Release

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2077218714

From mstrauss at openjdk.org  Wed May  7 09:31:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 May 2025 09:31:28 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
Message-ID: <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>

On Tue, 6 May 2025 14:55:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve synchronization in PreferenceProperties
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 258:
> 
>> 256:         }
>> 257: 
>> 258:         // This method must only be called on the FX application thread.
> 
> add `Toolkit.getToolkit().checkFxUserThread();` then?

The `Toolkit.getToolkit().checkFxUserThread()` check is in the calling method.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077222882

From kcr at openjdk.org  Wed May  7 13:09:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 13:09:27 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <IfUQP_hYPJaPum89UjvidPXwDqJAsrI4hwuOHDip4tE=.4e7c34da-a859-4956-8f8f-0e91baef4fcb@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
 <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
 <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>
 <IfUQP_hYPJaPum89UjvidPXwDqJAsrI4hwuOHDip4tE=.4e7c34da-a859-4956-8f8f-0e91baef4fcb@github.com>
Message-ID: <tnZo0xENgKXz2ZXc8Zi2kQVYHhfi2qeL2usGg_eJ2oU=.0b7c1e30-873a-4935-8b2d-3618692371bf@github.com>

On Wed, 7 May 2025 09:16:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> PlatformPreferences.update() seems to be called only from the fx thread, if I read the code right.  What happens when the Scene is created in a bg thread and a listener added to its preferences, and an event is fired?  Will the statement `#1` be still valid?  (I don't see any code that delays the dispatch until after the Scene is shown).
>> 
>> `#2` - all this is good, but we seem to hand the gun to user and say: here, shoot yourself in the foot.  And they do.  I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it, so who am I to say otherwise?
>
> `NullCoalescingPropertyBase` (used in `ScenePreferences`) is initially disconnected. It will set its initial value to the value is reads from `PlatformPreferences`, but it will not subscribe to change notifications. The reason for this is to prevent a scene that is created on a background thread from immediately receiving change notifications on the FX thread, which could not only potentially corrupt the property state (because they're not concurrently thread-safe), but also mess up the application state.
> 
> When the scene is shown, `NullCoalescingPropertyBase` will subscribe to change notifications from `PlatformPreferences`, because now we're safely on the FX thread. The code for that is in ScenePreferences:L142.

> I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it

Your objection is noted, but we are not going to relitigate this. JavaFX explicitly allows creation and modification of a scene graph on a thread other than the JavaFX application thread up to the point before that scene is attached to a window.

This means that we do need to be careful in our implementation, especially avoiding anything that might run on the application thread prior to the scene becoming "live". Sometimes that means deferring the adding of listeners as was recently done for charts. It sounds like that's what is being done here by deferring the subscription to platform preferences until the scene is shown.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077589320

From jhendrikx at openjdk.org  Wed May  7 13:28:29 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 May 2025 13:28:29 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <tnZo0xENgKXz2ZXc8Zi2kQVYHhfi2qeL2usGg_eJ2oU=.0b7c1e30-873a-4935-8b2d-3618692371bf@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
 <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
 <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>
 <IfUQP_hYPJaPum89UjvidPXwDqJAsrI4hwuOHDip4tE=.4e7c34da-a859-4956-8f8f-0e91baef4fcb@github.com>
 <tnZo0xENgKXz2ZXc8Zi2kQVYHhfi2qeL2usGg_eJ2oU=.0b7c1e30-873a-4935-8b2d-3618692371bf@github.com>
Message-ID: <RYg2CXGQxLXi4K9FkhaeWNQD3htSQd43Fltb-ntUICk=.197ad866-25dd-4400-b7e3-eb1315610926@github.com>

On Wed, 7 May 2025 13:06:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> `NullCoalescingPropertyBase` (used in `ScenePreferences`) is initially disconnected. It will set its initial value to the value is reads from `PlatformPreferences`, but it will not subscribe to change notifications. The reason for this is to prevent a scene that is created on a background thread from immediately receiving change notifications on the FX thread, which could not only potentially corrupt the property state (because they're not concurrently thread-safe), but also mess up the application state.
>> 
>> When the scene is shown, `NullCoalescingPropertyBase` will subscribe to change notifications from `PlatformPreferences`, because now we're safely on the FX thread. The code for that is in ScenePreferences:L142.
>
>> I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it
> 
> Your objection is noted, but we are not going to relitigate this. JavaFX explicitly allows creation and modification of a scene graph on a thread other than the JavaFX application thread up to the point before that scene is attached to a window.
> 
> This means that we do need to be careful in our implementation, especially avoiding anything that might run on the application thread prior to the scene becoming "live". Sometimes that means deferring the adding of listeners as was recently done for charts. It sounds like that's what is being done here by deferring the subscription to platform preferences until the scene is shown.

@kevinrushforth ... what about manipulating a Scene that was at some point attached to a Window?  I mean, I've built a solution specifically for just-in-time registration **and** unregistration of listeners.  So IMHO when a Scene is detached or the window is no longer showing (basically any time it doesn't have a peer) then listeners need to detach as well (and re-attach when that situation changes again).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077627120

From lkostyra at openjdk.org  Wed May  7 14:03:23 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 7 May 2025 14:03:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
Message-ID: <3GX2phXtO0jM1eYtPYoB20SmbOsx4UgDRPDe7_0OlPM=.5c2c9153-83b8-4ade-bf40-34314aa54ebd@github.com>

On Wed, 7 May 2025 09:30:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix non-debug build

I think the GTK changes are fine, however the tests need some addressing.

On Linux (Ubuntu 24.04.2 VM) I see consistently failing two tests:

    StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [1] DECORATED
    StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [2] UNDECORATED


Not sure for the reason for these, but it is a similar failure to Windows ones listed below - line 436 `assertTrue(stage1.isFocused())` fails.

Occasionally I also see `StageMixedSizeTest. testSetHeightOnlyAfterShownOnContentSizeWindow(StageStyle) [1] DECORATED` fail - it might be something timing related.

As @beldenfox mentioned, on Windows 11 the situation with the new tests is a bit worse. I see consistent failures in:

    SizingTest. testMinSize(StageStyle) [1] DECORATED
    SizingTest. testMinSize(StageStyle) [2] UNDECORATED
    SizingTest. testMinSize(StageStyle) [3] TRANSPARENT
    SizingTest. testMinSize(StageStyle) [4] UTILITY
    StageLocationTest. testMove(StageStyle) [1] DECORATED
    StageOwnershipTest. testChildStageWithoutModality(StageStyle) [1] DECORATED
    StageOwnershipTest. testChildStageWithoutModality(StageStyle) [2] UNDECORATED
    StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [1] DECORATED
    StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [2] UNDECORATED
    StageOwnershipTest. testIconfyRestoreChildren(StageStyle) [1] DECORATED
    StageOwnershipTest. testIconfyRestoreChildren(StageStyle) [2] UNDECORATED
    StageOwnershipTest. testLayeredModality(StageStyle) [1] DECORATED
    StageOwnershipTest. testLayeredModality(StageStyle) [2] UNDECORATED


Re: `SizingTest.testMinSize` - these tests all fail for the same reason that seems unrelated to your changes. Stage has min size limit set properly and it is respected by the OS, however JFX still returns smaller width/height. This is _despite_ the window having physically the same dimensions - in other words, Stage does not physically shrink, but JFX returns smaller width/height regardless, causing the Stage state to desync. This should be filed as a new JBS bug and fixed separately, I would set these tests to ignored/disabled on Windows for the time being with comment containing related JDK issue number.

Re: `StageLocationTest` - I added a comment in code about this.

Re: `StageOwnershipTest` - those fail when questioning APIs like `isIconified` and `isFocused`. We've already had some issues with focus on Windows 11 that I was trying to resolve ([JDK-8351357](https://bugs.openjdk.org/browse/JDK-8351357)) but it seems unrelated (my local hacky-fix-patch did not help it). I think this requires some more analysis to fully determine what is up.

tests/system/src/test/java/test/robot/javafx/stage/StageLocationTest.java line 91:

> 89:                     stage.setY(Y);
> 90:                 },
> 91:                 stage::show,

On my Windows 11 machine this consistently fails for DECORATED stage, which is the very first test to be done from the collection. My guess is that this misses a `CountDownLatch` or some other way to ensure the Stage is fully shown.

I would also add a similar latch wait to other tests in this file. A common `showStage` method of sorts that calls `stage::show` and then waits for the latch seems to me like the best route. Plenty of other system tests use this pattern if you need to source the solution from somewhere.

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-2821812695
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2077664569

From kcr at openjdk.org  Wed May  7 14:22:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 14:22:21 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v4]
In-Reply-To: <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
Message-ID: <eOQSdvsLNxRJPJhcBzZ6_hwr9zCLXFsYtOmcFKG6NQ8=.f0c9388f-d087-4858-b83b-0e10e5433946@github.com>

On Mon, 5 May 2025 21:28:08 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8355012.modenaCss
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Created ModenaTest
>  - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1801#pullrequestreview-2821951341

From kcr at openjdk.org  Wed May  7 14:28:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 14:28:26 GMT
Subject: RFR: 8345348: CSS media feature queries [v21]
In-Reply-To: <RYg2CXGQxLXi4K9FkhaeWNQD3htSQd43Fltb-ntUICk=.197ad866-25dd-4400-b7e3-eb1315610926@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <rMlehwpEgYQAi4trA8FjSLMwTFrtjFMck_OHKjM5RkI=.5de18be8-86ec-404c-8a8c-8b6f9201725f@github.com>
 <KO1Rk4OyqHamtUYhKl6K_xOFRIfqgXfuRMznbIIyjVc=.98b77c95-7102-422d-b79d-6fe096270c61@github.com>
 <his3c9-eezf-Ly50L817G14k0lnn_Og6pEPVwm5KTqQ=.74695a82-73eb-4d0a-bfb4-63609610409b@github.com>
 <xMDp0vl6s1C9X-NfaIWGiAtBto_jSAg6VJreyNgtAik=.a549bd6a-cbec-4dd6-871a-a9b9506e1ce2@github.com>
 <Nf6bGu1O85Ukk1mz1057-G6rmwf5g3DEmZAG2Y7UqRA=.6e8da915-f833-403b-a114-b431dfbc9dd8@github.com>
 <eJUIrg8JJLXZ9wiHod0eHo2wruFGEqMgV1t1SRexIFs=.01f02a40-72a2-4605-a950-b07a1d4cdad4@github.com>
 <XvYQ2gZa_O8JtTd6fnPharAJhXqEplarufsaVMrwmMs=.201adbe6-7479-4131-9c19-a55e29e753c4@github.com>
 <LLHRV7sIAAidDbp2vG1yHo_JRn30vJiRxnZ_vy1XUX4=.a121229e-5f5d-48e1-9802-ccf6620c8d8d@github.com>
 <yksbydHAmR8Uu1SY5ZKuO5GoZPd2fxgFm7MV64dvT4Q=.adccec77-7890-41c3-943a-08edfe32f251@github.com>
 <FQO1bdADIPn-9G1V1vDaNO2hnAw5JrCoG-V
 uwgIRfKU=.ae5ccfc8-4673-4183-b9bf-17f5513f70cb@github.com>
 <yGKoR-kVQaEto-fLlgz0Blo6GHN04Z7UMlMzGr3oMYc=.49af7bb8-57e7-41b8-b154-405f11868728@github.com>
 <zWxfYGN3QducB04atmGNONZzl5TqYPmLS3XC2tAl9EI=.c4df2b58-f398-454e-9e2a-9430acf66f65@github.com>
 <IfUQP_hYPJaPum89UjvidPXwDqJAsrI4hwuOHDip4tE=.4e7c34da-a859-4956-8f8f-0e91baef4fcb@github.com>
 <tnZo0xENgKXz2ZXc8Zi2kQVYHhfi2qeL2usGg_eJ2oU=.0b7c1e30-873a-4935-8b2d-3618692371bf@github.com>
 <RYg2CXGQxLXi4K9FkhaeWNQD3htSQd43Fltb-ntUICk=.197ad866-25dd-4400-b7e3-eb1315610926@github.com>
Message-ID: <L7GpFmcP8XlrzM8qggPhmNk4aqm0JgM_dfG-iHJV6CY=.e774df8a-d25d-449f-b75c-61b79b9206d9@github.com>

On Wed, 7 May 2025 13:26:01 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> I think it (creating things in a background thread) was a mistake in the first place, but there seems to be zero desire to change it
>> 
>> Your objection is noted, but we are not going to relitigate this. JavaFX explicitly allows creation and modification of a scene graph on a thread other than the JavaFX application thread up to the point before that scene is attached to a window.
>> 
>> This means that we do need to be careful in our implementation, especially avoiding anything that might run on the application thread prior to the scene becoming "live". Sometimes that means deferring the adding of listeners as was recently done for charts. It sounds like that's what is being done here by deferring the subscription to platform preferences until the scene is shown.
>
> @kevinrushforth ... what about manipulating a Scene that was at some point attached to a Window?  I mean, I've built a solution specifically for just-in-time registration **and** unregistration of listeners.  So IMHO when a Scene is detached or the window is no longer showing (basically any time it doesn't have a peer) then listeners need to detach as well (and re-attach when that situation changes again).

The Scene specification says "A Scene may be created and modified on any thread until it is attached to a Window that is showing. After that, it must be modified only on the JavaFX Application Thread."

So that doesn't allow for "transferring it" back to a background thread when you remove it. If we wanted to relax that, it would take additional work for nodes that use animation or setup other listeners that fire on the JavaFX application thread.

The use case for doing so seems pretty narrow, and I'm not sure it is worth it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077760589

From zelmidaoui at openjdk.org  Wed May  7 14:33:24 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 7 May 2025 14:33:24 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v4]
In-Reply-To: <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
Message-ID: <2MslrcQ3InIRY1iDCzxNuoqmB57sIYZmeU7yAf2MuiE=.c58f8791-685b-49af-b581-6ebd09e178b3@github.com>

On Mon, 5 May 2025 21:28:08 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8355012.modenaCss
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Created ModenaTest
>  - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

Thank you all for your reviews and feedback!

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2858815651

From duke at openjdk.org  Wed May  7 14:33:24 2025
From: duke at openjdk.org (duke)
Date: Wed, 7 May 2025 14:33:24 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v4]
In-Reply-To: <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
Message-ID: <DammZZQbOTMnFtAkbiANLShgO4UZE8lQIL9aW3WQ0rU=.819f6828-526f-48f6-9f2a-31ff5db657c2@github.com>

On Mon, 5 May 2025 21:28:08 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8355012.modenaCss
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Created ModenaTest
>  - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

@Ziad-Mid 
Your change (at version e3ad18c0654b6bac0b16f0001d6a35049676b062) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2858819581

From angorya at openjdk.org  Wed May  7 14:39:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 14:39:27 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
Message-ID: <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>

On Wed, 7 May 2025 09:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 258:
>> 
>>> 256:         }
>>> 257: 
>>> 258:         // This method must only be called on the FX application thread.
>> 
>> add `Toolkit.getToolkit().checkFxUserThread();` then?
>
> The `Toolkit.getToolkit().checkFxUserThread()` check is in the calling method.

since it's a public method accessible to the application via the same method, I think you either need to make it private or add the check.

>> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 312:
>> 
>>> 310: 
>>> 311:         // This method must only be called when synchronized on 'mutex'.
>>> 312:         public void updateEffectiveValue() {
>> 
>> maybe make this method private then: the instance of this class is available via `Platform.getPreferences()` if I read this correctly
>
> No, the instance of `PreferenceProperties` is only stored as a private field in `PlatformPreferences`. I'm usually using public methods in nested classes to indicate that the method is supposed to be called from outside of the nested class. That's not strictly necessary, but I think it serves to differentiate them from "purely" private methods.

let me try again:

`Platform.getPreferences()` returns an instance of `PlatformPreferences`
`PlatformPreferences.colorSchemeProperty()` returns a `ColorSchemeProperty` with a public `updateEffectiveValue()`

the app can use reflection to invoke a public method, though admittedly in a convoluted way.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077789898
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077785625

From angorya at openjdk.org  Wed May  7 14:41:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 14:41:28 GMT
Subject: RFR: 8355012: JavaFX modena.css -fx-highlight-text-fill bug [v4]
In-Reply-To: <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
 <uxbuliPqREZpAoS9FWO4gAwlbFO3_LrYqGsInfrTdLw=.083841d8-9248-492a-b8a2-c26bbc8a8022@github.com>
Message-ID: <9OWfgOcWITZoeC8_1w0D6D827RO-IPXmmL9qnqgZk1g=.21f748b8-66ef-43fc-bd6b-6f30f8d14f57@github.com>

On Mon, 5 May 2025 21:28:08 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .
>
> Ziad El Midaoui 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8355012.modenaCss
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Added standard copyright, javadoc and changed file name to TextInputControlModenaTest
>  - Created ModenaTest
>  - Changed value of -fx-highlight-text-fill to be dynamically set and added tests

good job!

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

PR Comment: https://git.openjdk.org/jfx/pull/1801#issuecomment-2858857246

From zelmidaoui at openjdk.org  Wed May  7 14:41:29 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 7 May 2025 14:41:29 GMT
Subject: Integrated: 8355012: JavaFX modena.css -fx-highlight-text-fill bug
In-Reply-To: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
References: <Pmq8umlbV3OWQ1g-r5576lHh3SxsiS--cdRKBOPHTNA=.b5024829-fdb4-4b27-82e0-8479d489ab78@github.com>
Message-ID: <m0aF7rCRdB-jAR_sItomsL50XMHppKuPhoJf82qziYo=.d9f63e44-453d-4249-8cdc-442ea0a5115e@github.com>

On Thu, 1 May 2025 22:08:46 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue was happening because `-fx-highlight-text-fill` was set to white , so when the background color is bright (>60% brightness ) the text is not visible , the solution is to change the value to be dynamically set depending on the level of brightness of the background this is done by `-fx-focused-text-base-color` .

This pull request has now been integrated.

Changeset: bffc32bf
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bffc32bfef9b48478382180beefdb84f2b8651c6
Stats:     140 lines in 2 files changed: 139 ins; 0 del; 1 mod

8355012: JavaFX modena.css -fx-highlight-text-fill bug

Reviewed-by: angorya, kcr

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

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

From kcr at openjdk.org  Wed May  7 14:46:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 14:46:32 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
Message-ID: <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>

On Wed, 7 May 2025 14:35:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> No, the instance of `PreferenceProperties` is only stored as a private field in `PlatformPreferences`. I'm usually using public methods in nested classes to indicate that the method is supposed to be called from outside of the nested class. That's not strictly necessary, but I think it serves to differentiate them from "purely" private methods.
>
> let me try again:
> 
> `Platform.getPreferences()` returns an instance of `PlatformPreferences`
> `PlatformPreferences.colorSchemeProperty()` returns a `ColorSchemeProperty` with a public `updateEffectiveValue()`
> 
> the app can use reflection to invoke a public method, though admittedly in a convoluted way.

No, an application would not be able to do that. A getter whose implementation happens to return a subtype in a non-exported package does not allow the caller of that getter to access any methods in the non-exported class (even public ones). If it did, then you could never return a type that implements an interface, since all interface methods are public.

@mstr2 is right. There is no problem here that I can see.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077805709

From kcr at openjdk.org  Wed May  7 14:53:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 14:53:30 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
Message-ID: <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>

On Wed, 7 May 2025 14:44:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> let me try again:
>> 
>> `Platform.getPreferences()` returns an instance of `PlatformPreferences`
>> `PlatformPreferences.colorSchemeProperty()` returns a `ColorSchemeProperty` with a public `updateEffectiveValue()`
>> 
>> the app can use reflection to invoke a public method, though admittedly in a convoluted way.
>
> No, an application would not be able to do that. A getter whose implementation happens to return a subtype in a non-exported package does not allow the caller of that getter to access any methods in the non-exported class (even public ones). If it did, then you could never return a type that implements an interface, since all interface methods are public.
> 
> @mstr2 is right. There is no problem here that I can see.

Having said that, if the methods in question are not needed outside the package, consider making them package scope.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077824708

From angorya at openjdk.org  Wed May  7 14:57:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 14:57:25 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
Message-ID: <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>

On Wed, 7 May 2025 14:51:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> No, an application would not be able to do that. A getter whose implementation happens to return a subtype in a non-exported package does not allow the caller of that getter to access any methods in the non-exported class (even public ones). If it did, then you could never return a type that implements an interface, since all interface methods are public.
>> 
>> @mstr2 is right. There is no problem here that I can see.
>
> Having said that, if the methods in question are not needed outside the package, consider making them package scope.

yes it can:

--add-opens javafx.graphics/com.sun.javafx.application.preferences=andy_test



        var platformPreferences = Platform.getPreferences();
        var colorSchemeProperty = platformPreferences.colorSchemeProperty();
        Method m = colorSchemeProperty.getClass().getMethod("updateEffectiveValue");
        m.setAccessible(true);
        m.invoke(colorSchemeProperty);

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077835948

From angorya at openjdk.org  Wed May  7 15:14:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 15:14:27 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
 <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
 <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>
Message-ID: <5K_bSLMRTpwRyGo_8ysgZx5fEGtzQaWOgVjbZq8IsjM=.35e9516e-f99b-4f25-bceb-d5156c1b8d6a@github.com>

On Wed, 7 May 2025 15:09:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> yes it can:
>> 
>> --add-opens javafx.graphics/com.sun.javafx.application.preferences=andy_test
>> 
>> 
>> 
>>         var platformPreferences = Platform.getPreferences();
>>         var colorSchemeProperty = platformPreferences.colorSchemeProperty();
>>         Method m = colorSchemeProperty.getClass().getMethod("updateEffectiveValue");
>>         m.invoke(colorSchemeProperty);
>
>> --add-opens javafx.graphics/com.sun.javafx.application.preferences=andy_test
> 
> You can access any number of internal classes or methods with "--add-exports" or "--add-opens", so that is not a valid argument.

okay

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077889957

From kcr at openjdk.org  Wed May  7 15:14:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 15:14:27 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
 <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
Message-ID: <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>

On Wed, 7 May 2025 14:55:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> --add-opens javafx.graphics/com.sun.javafx.application.preferences=andy_test

You can access any number of internal classes or methods with "--add-exports" or "--add-opens", so that is not a valid argument.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077878369

From kcr at openjdk.org  Wed May  7 15:19:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 15:19:22 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <5K_bSLMRTpwRyGo_8ysgZx5fEGtzQaWOgVjbZq8IsjM=.35e9516e-f99b-4f25-bceb-d5156c1b8d6a@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
 <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
 <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>
 <5K_bSLMRTpwRyGo_8ysgZx5fEGtzQaWOgVjbZq8IsjM=.35e9516e-f99b-4f25-bceb-d5156c1b8d6a@github.com>
Message-ID: <-WQOYjleZPWNHvWxyJwvmc8c9TmPJYEAh6iAfZu06E0=.a9d95212-f28e-4f73-b0b9-e2d524f126e4@github.com>

On Wed, 7 May 2025 15:11:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> --add-opens javafx.graphics/com.sun.javafx.application.preferences=andy_test
>> 
>> You can access any number of internal classes or methods with "--add-exports" or "--add-opens", so that is not a valid argument.
>
> okay

Further, if you call `setAccessibile` in connection with `--add-opens`, which your above code snippet does, you can even call _private_ methods.

So at the risk of repeating myself, there is no concern that making this method public exposes it to applications. However, making it package-scope if it doesn't need to be public, is a best practice if it doesn't need to be accessed outside the package.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077898653

From angorya at openjdk.org  Wed May  7 15:26:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 15:26:28 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <-WQOYjleZPWNHvWxyJwvmc8c9TmPJYEAh6iAfZu06E0=.a9d95212-f28e-4f73-b0b9-e2d524f126e4@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
 <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
 <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>
 <5K_bSLMRTpwRyGo_8ysgZx5fEGtzQaWOgVjbZq8IsjM=.35e9516e-f99b-4f25-bceb-d5156c1b8d6a@github.com>
 <-WQOYjleZPWNHvWxyJwvmc8c9TmPJYEAh6i
 AfZu06E0=.a9d95212-f28e-4f73-b0b9-e2d524f126e4@github.com>
Message-ID: <hz98cSp5pz4BMhf-0knYM1BG9rdSt1XjJK4bVzbE_ys=.b1ebc8fd-58e5-467e-afc9-725df2e5dca2@github.com>

On Wed, 7 May 2025 15:16:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> okay
>
> Further, if you call `setAccessibile` in connection with `--add-opens`, which your above code snippet does, you can even call _private_ methods.
> 
> So at the risk of repeating myself, there is no concern that making this method public exposes it to applications. However, making it package-scope if it doesn't need to be public, is a best practice if it doesn't need to be accessed outside the package.

yes, I agree - thanks for the discussion!

(and `setAccessible()` is not needed with `--add-opens`)

I withdraw my comments - making these methods `private` is not needed, `public` or package-scope is fine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077914653

From zelmidaoui at openjdk.org  Wed May  7 15:40:29 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 7 May 2025 15:40:29 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning
Message-ID: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>

The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

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

Commit messages:
 - Fixed import error
 - Merge branch 'openjdk:master' into 8340344.TreeViewAlign
 - Fix by explicitly requesting layout on cells instead of changing default value
 - Merge branch 'openjdk:master' into 8340344.TreeViewAlign
 - Fixed default disclosure width

Changes: https://git.openjdk.org/jfx/pull/1715/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1715&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340344
  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1715.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1715/head:pull/1715

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

From zelmidaoui at openjdk.org  Wed May  7 15:40:30 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 7 May 2025 15:40:30 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <fzbnflFfwP0LR5qqQw79ZxACfCbQokFkwXOIJJvwiEY=.3f45297e-7a81-45ac-a533-1cac1043036a@github.com>

On Wed, 19 Feb 2025 16:45:54 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

.

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

PR Comment: https://git.openjdk.org/jfx/pull/1715#issuecomment-2818834579

From angorya at openjdk.org  Wed May  7 15:40:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 15:40:31 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <Oa1hfHZVwEpECOSJ5SI0gfUZ-HqYIqoeO1mZY5M3yWQ=.b9a39719-033f-4842-8a4d-ffcaf054711f@github.com>

On Wed, 19 Feb 2025 16:45:54 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 210:

> 208: 
> 209:         final double defaultDisclosureWidth = maxDisclosureWidthMap.containsKey(tree) ?
> 210:                 maxDisclosureWidthMap.get(tree) : 20;   // JDK-8119169: default width of default disclosure node

This is probably not a good solution: I think the root cause is not in that the default value is incorrect, but in that two different values are used in the same view (i.e. that it first uses the default value, then the value computed from the disclosure node, if I read the code correctly).

Could you please investigate?

I've linked the JBS ticket mentioned in the comment, take a look at the discussion there https://bugs.openjdk.org/browse/JDK-8119169 , especially the comment about variable width disclosure node.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r1962563133

From kizune at openjdk.org  Wed May  7 15:42:03 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 May 2025 15:42:03 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  - Added newlines where they were missing;
  - Removed ebug output;
  - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1796/files
  - new: https://git.openjdk.org/jfx/pull/1796/files/ce8dc77d..94bf9a1a

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

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

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

From lkostyra at openjdk.org  Wed May  7 15:45:26 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 7 May 2025 15:45:26 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
Message-ID: <S8H3unayjyxMGBQu6S8idbvGAAWVD_3LmnFA85EEhdo=.552986e3-077d-4587-9394-3534bfd43cc5@github.com>

On Wed, 7 May 2025 09:30:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix non-debug build

One more thing about `SizingTest.testMinSize` on Windows, I found this JBS bug - [JDK-8310845 - Size-restricted window reports incorrect dimensions on Linux](https://bugs.openjdk.org/browse/JDK-8310845) - which seems to be a similar problem, however on Windows instead of Linux.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2859093476

From angorya at openjdk.org  Wed May  7 15:46:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 15:46:24 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
Message-ID: <H954rP-CXYQ2cGuPIu-CbteMeuaslWqphYKanpo3AJc=.de5f058b-1562-45c4-aa52-c62ba7c7f66f@github.com>

On Wed, 7 May 2025 15:42:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Added newlines where they were missing;
>   - Removed ebug output;
>   - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

so the group protocol is not needed for progress bar/indicator?

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2859101223

From pavelturk2000 at gmail.com  Wed May  7 15:52:18 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 7 May 2025 18:52:18 +0300
Subject: CodeArea: how to get the indexes of the first visible paragraph and
 the last one?
Message-ID: <c36d2cda-1e9f-44af-86bd-52ad55e8d5a7@gmail.com>

Could anyone say how to get the indexes of the first visible paragraph and the last visible paragraph.
If it currently possible. I am talking about indexes relative to all paragraphs in the code area.

Best regards, Pavel

From andy.goryachev at oracle.com  Wed May  7 15:56:40 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 May 2025 15:56:40 +0000
Subject: CodeArea: how to get the indexes of the first visible paragraph
 and the last one?
In-Reply-To: <c36d2cda-1e9f-44af-86bd-52ad55e8d5a7@gmail.com>
References: <c36d2cda-1e9f-44af-86bd-52ad55e8d5a7@gmail.com>
Message-ID: <BYAPR10MB30131628C7F859962A154B15E588A@BYAPR10MB3013.namprd10.prod.outlook.com>

RichTextArea.getTextPosition() should be able to give the answer.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 08:52
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: how to get the indexes of the first visible paragraph and the last one?
Could anyone say how to get the indexes of the first visible paragraph and the last visible paragraph.
If it currently possible. I am talking about indexes relative to all paragraphs in the code area.

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250507/d7ab0f31/attachment.htm>

From zelmidaoui at openjdk.org  Wed May  7 15:56:57 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 7 May 2025 15:56:57 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v2]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Update TreeCellSkin.java

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/34e8cce1..a07148a2

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

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

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

From pavelturk2000 at gmail.com  Wed May  7 16:28:53 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 7 May 2025 19:28:53 +0300
Subject: CodeArea: how to convert offset to TextPos?
Message-ID: <9a9c0e3a-70ee-4fa1-b967-cd44f40402f7@gmail.com>

Could anyone say how to convert offset to TextPos in CodeArea?

For example, in RTFX CodeArea we have:

var pos = codeArea.offsetToPosition(offset, Bias.Backward);
var paragraph = pos.getMajor();

Best regards, Pavel

From duke at openjdk.org  Wed May  7 16:41:37 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:41:37 GMT
Subject: RFR: 8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not
 receiving events [v2]
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:

  8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1755/files
  - new: https://git.openjdk.org/jfx/pull/1755/files/e999e891..35fa7fb4

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

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

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

From duke at openjdk.org  Wed May  7 16:51:21 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 7 May 2025 16:51:21 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <UVUMGvTh0HO1x-2GFLo4IeJO_Hau66za596NS0PCnIM=.d2426c4c-4787-447c-9587-91b6dbf8c462@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

I implemented the feedback and changed the title.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2859289792

From kcr at openjdk.org  Wed May  7 17:01:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 May 2025 17:01:48 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v16]
In-Reply-To: <c6L7IlB_H3bvNeKyzb4Q7uAbwDjwp--kb7AgOX-H_EE=.7725335b-5f3f-484d-9dd9-c2e6d9a6e222@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <4X7i8P7G3RDnC78ucuU42vulISLNMqRJPwWQ2UGzvXo=.8230ce01-b3a8-4f0e-b14e-577790ff3330@github.com>
 <c6L7IlB_H3bvNeKyzb4Q7uAbwDjwp--kb7AgOX-H_EE=.7725335b-5f3f-484d-9dd9-c2e6d9a6e222@github.com>
Message-ID: <KDQw5ra5LrDkUx51h4DdyR85rENqDv4dbakqY7uHnQQ=.864eed0b-a914-4ad8-9db2-f69fb54ccdea@github.com>

On Tue, 6 May 2025 12:24:04 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix TestStage conflicting value listener
>
> There is a test that is failing on `StageOwnershipTest` due to the focus stealing prevention mechanism that exists on gnome that I need to address.
> 
> Other than that, all tests pass on Ubuntu 24.04 on Xwayland and Xorg.

@tsayao Can you merge in the latest upstream master? We recently updated the compiler toolchain on Linux to GCC 14.2, so merging in that commit will trigger a GHA run with GCC 14.2 to ensure that there are no problems.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2859346411

From andy.goryachev at oracle.com  Wed May  7 17:04:18 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 May 2025 17:04:18 +0000
Subject: CodeArea: how to convert offset to TextPos?
In-Reply-To: <9a9c0e3a-70ee-4fa1-b967-cd44f40402f7@gmail.com>
References: <9a9c0e3a-70ee-4fa1-b967-cd44f40402f7@gmail.com>
Message-ID: <BYAPR10MB3013772CB633B370812C4E9DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>

There is no dedicated method to do that.  The application can iterate over paragraphs to compute the text position, just keep in mind that the model can be quite large and it a) will take a lot of iterations and b) the result may exceed 2^31 (i.e. need to be 'long').

The same is true for the reverse operation, TextPos -> offset.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 09:29
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: how to convert offset to TextPos?
Could anyone say how to convert offset to TextPos in CodeArea?

For example, in RTFX CodeArea we have:

var pos = codeArea.offsetToPosition(offset, Bias.Backward);
var paragraph = pos.getMajor();

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250507/57c7bee1/attachment.htm>

From mstrauss at openjdk.org  Wed May  7 17:13:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 May 2025 17:13:58 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v73]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <oMCEs1TApj96mpYTBDr9ik2yGQC4JxgWYoH5KRrAqmU=.b9b6167e-7d52-4bbd-8c8a-a12b7b1d9bd9@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits:

 - Merge branch 'master' into feature/extended-window
 - reapply overlay CSS
 - Merge branch 'master' into feature/extended-window
 - simplify header area picking
 - Fix top resize border on Windows
 - Merge branch 'master' into feature/extended-window
 - doc change
 - add HeaderDragType
 - add MenuBar to stage tester
 - documentation
 - ... and 84 more: https://git.openjdk.org/jfx/compare/bffc32bf...e09adfe5

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=72
  Stats: 6805 lines in 76 files changed: 6114 ins; 517 del; 174 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

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

From angorya at openjdk.org  Wed May  7 17:15:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 17:15:23 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
Message-ID: <AChGOvdNFf9nxLnEFuKWNT3ZbpebGuGrWh8OXvBrnPI=.f609bb57-250a-4207-9684-b4eb37ed0d05@github.com>

On Wed, 7 May 2025 15:42:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Added newlines where they were missing;
>   - Removed ebug output;
>   - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

Since you removed the group protocol from this PR, perhaps unlink the ticket [JDK-8351773](https://bugs.openjdk.org/browse/JDK-8351773) ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2859401486

From andy.goryachev at oracle.com  Wed May  7 17:29:11 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 May 2025 17:29:11 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
Message-ID: <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>

This bug is still percolating through the system.  I'll respond once I get it.

Thank you for all the questions and the feedback!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 14:13
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
'-fx-background-color' for RichParagraph segment.

I've opened an issue today, so, when it is approved there won't be any questions.

Best regards, Pavel
On 5/6/25 00:04, Andy Goryachev wrote:
Will not happen.  CSS compatibility with a third party library is not a requirement in this case.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:59
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
To be as clear as possible, here's what I need:

.test {
     -fx-set-somehow-background-color: green;
}

var builder = RichParagraph.builder();
builder.addWithStyleNames(segment, "test");

because, in parallel for RTFX I simply use its stylesheet:

.test {
     -rtfx-background-color: green;
}


So, for both code areas, I use same style classes for styling paragraph segments.

Best regards, Pavel
On 5/5/25 23:20, Andy Goryachev wrote:
Right, the API are missing currently.  I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.  Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.  Right?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:10
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel
On 5/5/25 22:54, Andy Goryachev wrote:
You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel
On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel




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

From mfox at openjdk.org  Wed May  7 17:30:21 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 7 May 2025 17:30:21 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
Message-ID: <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>

On Wed, 7 May 2025 09:30:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix non-debug build

tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 343:

> 341:                 () -> {
> 342:                     assertTrue(stage0.isIconified());
> 343:                     assertTrue(stage1.isIconified());

When a window is iconified I would expect the OS to hide any owned windows but not iconify them. For example, the owned windows should not appear as thumbnails in the dock or task bar. If we want these to be reported as iconified we would have to update glass to do that.

My first impulse is to not change anything but currently JavaFX has no way of knowing that the owned windows have changed state and can't be drawn to. We can't report them as hidden because that means something else in JavaFX. Modifying glass to report them as iconified might actually be the right thing to do even though they're not actually iconified.

tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 436:

> 434:                 stage2::show,
> 435:                 stage2::close,
> 436:                 () -> assertTrue(stage1.isFocused()));

This test looks incorrect. If closing an app modal window should focus the parent (and I think it should) then stage0 should be focused.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2078098880
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2078102455

From pavelturk2000 at gmail.com  Wed May  7 17:30:41 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 7 May 2025 20:30:41 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
 <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>

Andy, thank you very much for your help!

Best regards, Pavel

On 5/7/25 20:29, Andy Goryachev wrote:
>
> This bug is still percolating through the system.? I'll respond once I get it.
>
> Thank you for all the questions and the feedback!
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 5, 2025 at 14:13
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
> The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
> '-fx-background-color' for RichParagraph segment.
>
> I've opened an issue today, so, when it is approved there won't be any questions.
>
> Best regards, Pavel
>
> On 5/6/25 00:04, Andy Goryachev wrote:
>
>     Will not happen.? CSS compatibility with a third party library is not a requirement in this case.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 5, 2025 at 13:59
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>     To be as clear as possible, here's what I need:
>
>     .test {
>     ???? -fx-set-somehow-background-color: green;
>     }
>
>     var builder = RichParagraph.builder();
>     builder.addWithStyleNames(segment, "test");
>
>     because, in parallel for RTFX I simply use its stylesheet:
>
>     .test {
>     ???? -rtfx-background-color: green;
>     }
>
>
>     So, for both code areas, I use same style classes for styling paragraph segments.
>
>     Best regards, Pavel
>
>     On 5/5/25 23:20, Andy Goryachev wrote:
>
>         Right, the API are missing currently.? I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.? Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.? Right?
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Monday, May 5, 2025 at 13:10
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>         Andy, thank you very much for your help.
>
>         That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
>         and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.
>
>         Well, technically I could, but it just wouldn?t make any sense.
>
>         Best regards, Pavel
>
>         On 5/5/25 22:54, Andy Goryachev wrote:
>
>             You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
>             JDK-8355774 is pretty high on my list of things to do.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Monday, May 5, 2025 at 12:47
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>             Hello, Andy
>
>             Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
>             I have just opened an issue with ID : 9078469.
>
>             Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
>             that it's impossible to work without it.
>
>             Best regards, Pavel
>
>             On 5/5/25 22:09, Andy Goryachev wrote:
>
>                 Dear Pavel:
>
>                 Can you clarify what you are trying to do exactly?
>
>                 If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>                 If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS. There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Saturday, May 3, 2025 at 10:07
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *CodeArea: -fx-background-color doesn't work.
>
>                 For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>                 Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>                 Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>                 they?have?-rtfx-background-color.
>
>                 public?class?JfxCodeArea?extends?Application?{
>
>                 ?????@Override
>                 ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>                 ?????????String?text?=?"""
>                 ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>                 ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>                 ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>                 ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>                 ???????????????????????""";
>
>                 ?????????String?css?=?"""
>                 ?????????????.test?{
>                 ?????????????????-fx-font-weight:?bold;
>                 ?????????????????-fx-fill:?red;
>                 ?????????????????-fx-background-color:?green;
>                 ?????????????}
>
>                 ?????????""";
>                 ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>                 ?????????CodeArea?codeArea?=?new?CodeArea();
>                 ?????????codeArea.getStylesheets().add(data);
>
>                 ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>                 ?????????????@Override
>                 ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>                 ?????????????????var?builder?=?RichParagraph.builder();
>                 ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>                 ?????????????????return?builder.build();
>                 ?????????????}
>
>                 ?????????????@Override
>                 ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>                 ?????????????}
>                 ?????????});
>
>                 ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>                 ?????????var?button?=?new?Button("Go!");
>                 ?????????button.setOnAction(e?->?codeArea.setText(text));
>                 ?????????VBox?root?=?new?VBox(codeArea,?button);
>                 ?????????Scene?scene?=?new?Scene(root,?600,?200);
>                 ?????????primaryStage.setScene(scene);
>                 ?????????primaryStage.show();
>
>                 ?????}
>
>                 ?????public?static?void?main(String[]?args)?{
>                 ?????????launch(args);
>                 ?????}
>                 }
>
>                 Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250507/329935ef/attachment-0001.htm>

From tsayao at openjdk.org  Wed May  7 17:54:36 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 17:54:36 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v19]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <mjfhjVCZ2t1fFtdXkgRzvIKmcdM-EQkfP5QKvu-qam0=.4242a2ab-0b00-477b-a623-f37b52cf6be3@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into 8354943
 - Fix non-debug build
 - Review fixes
 - Fix TestStage conflicting value listener
 - Merge master
 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	tests/system/src/test/java/test/javafx/scene/RestoreSceneSizeTest.java
 - TestStage
 - - Improve TestStage
   - Notify maximize/fullscreen before show on native side
 - Fix test on SizingTest
 - Remove state precedence tests
 - ... and 10 more: https://git.openjdk.org/jfx/compare/bffc32bf...699ed85f

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=18
  Stats: 3971 lines in 28 files changed: 2719 ins; 759 del; 493 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From andy.goryachev at oracle.com  Wed May  7 18:16:19 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 May 2025 18:16:19 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
 <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>
Message-ID: <BYAPR10MB3013772564627E93FB27059AE588A@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you for the feedback!

I finally got the ticket - https://bugs.openjdk.org/browse/JDK-8356436 .  It's a dup of https://bugs.openjdk.org/browse/JDK-8355774 , essentially.  Once the missing APIs are added, you'll be able to style the highlights with CSS:

RichParagraph.Builder#addHighlight(int start, int length, String ... css)

-andy

P.S.  In some of your code, you do css.toArray() for each paragraph.  I wonder if you should just create a bunch of styles statically instead - like a document stylesheet, since these names do not change at all.




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 10:30
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help!

Best regards, Pavel
On 5/7/25 20:29, Andy Goryachev wrote:
This bug is still percolating through the system.  I'll respond once I get it.

Thank you for all the questions and the feedback!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 14:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
'-fx-background-color' for RichParagraph segment.

I've opened an issue today, so, when it is approved there won't be any questions.

Best regards, Pavel
On 5/6/25 00:04, Andy Goryachev wrote:
Will not happen.  CSS compatibility with a third party library is not a requirement in this case.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:59
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
To be as clear as possible, here's what I need:

.test {
     -fx-set-somehow-background-color: green;
}

var builder = RichParagraph.builder();
builder.addWithStyleNames(segment, "test");

because, in parallel for RTFX I simply use its stylesheet:

.test {
     -rtfx-background-color: green;
}


So, for both code areas, I use same style classes for styling paragraph segments.

Best regards, Pavel
On 5/5/25 23:20, Andy Goryachev wrote:
Right, the API are missing currently.  I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.  Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.  Right?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:10
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel
On 5/5/25 22:54, Andy Goryachev wrote:
You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel
On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel





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

From tsayao at openjdk.org  Wed May  7 18:47:58 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 18:47:58 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
Message-ID: <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>

On Wed, 7 May 2025 17:11:17 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-debug build
>
> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 436:
> 
>> 434:                 stage2::show,
>> 435:                 stage2::close,
>> 436:                 () -> assertTrue(stage1.isFocused()));
> 
> This test looks incorrect. If closing an app modal window should focus the parent (and I think it should) then stage0 should be focused.

But `stage1` is the owner of `stage2`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2078282466

From tsayao at openjdk.org  Wed May  7 18:50:59 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 18:50:59 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <S8H3unayjyxMGBQu6S8idbvGAAWVD_3LmnFA85EEhdo=.552986e3-077d-4587-9394-3534bfd43cc5@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <S8H3unayjyxMGBQu6S8idbvGAAWVD_3LmnFA85EEhdo=.552986e3-077d-4587-9394-3534bfd43cc5@github.com>
Message-ID: <jCz7tku60grrXHNQ614zkKfeqfDfuiaJHyKOCczi4rA=.ce9dcaf1-4d4a-47ba-8ec7-c891ac4b5a9d@github.com>

On Wed, 7 May 2025 15:41:02 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> One more thing about `SizingTest.testMinSize` on Windows, I found this JBS bug - [JDK-8310845 - Size-restricted window reports incorrect dimensions on Linux](https://bugs.openjdk.org/browse/JDK-8310845) - which seems to be a similar problem, however on Windows instead of Linux.

It might be because JavaFX would change the property and then pass it to glass native. I had to make the native side report back the actual dimensions if they could not be applied.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2859877279

From pavelturk2000 at gmail.com  Wed May  7 18:53:51 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 7 May 2025 21:53:51 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB3013772564627E93FB27059AE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
 <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>
 <BYAPR10MB3013772564627E93FB27059AE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <fa95547c-f53f-4141-8c4d-855a5f6e4422@gmail.com>

I've read your comments on the issue and was actually in the process of writing to you when I received your message.
Let me clarify a critically important point.

Currently, to style segment text using CSS style classes, we use this method:
RichParagraph.Builder.addWithStyleNames(String text, String... css) - ONE METHOD FOR ALL STYLE CLASSES.

If I understand correctly (and I might be wrong!), you're suggesting using a DIFFERENT method for background color styling:
RichParagraph.Builder#addHighlight(int start, int end, String... styles).

Could you please confirm whether RichParagraph.Builder.addWithStyleNames(String text, String... css) can also be used for background coloring?

For example, we know that user wants to add style classes "foo" and "bar" to a text from from 5 to 20. We do not know IF THESE STYLES
SET BACKGROUND COLOR. Or should we ask an user to name a class this way - "foo-bg"?

Best regards, Pavel

On 5/7/25 21:16, Andy Goryachev wrote:
>
> Thank /you/ for the feedback!
>
> I finally got the ticket - https://bugs.openjdk.org/browse/JDK-8356436 .? It's a dup of https://bugs.openjdk.org/browse/JDK-8355774 , essentially.? Once the missing APIs are added, you'll be able to style the highlights with CSS:
>
> RichParagraph.Builder#addHighlight(int start, int length, String ... css)
>
> -andy
>
> P.S. In some of your code, you do css.toArray() for each paragraph.? I wonder if you should just create a bunch of styles statically instead - like a document stylesheet, since these names do not change at all.
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, May 7, 2025 at 10:30
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> Andy, thank you very much for your help!
>
> Best regards, Pavel
>
> On 5/7/25 20:29, Andy Goryachev wrote:
>
>     This bug is still percolating through the system.? I'll respond once I get it.
>
>     Thank you for all the questions and the feedback!
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 5, 2025 at 14:13
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>     No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
>     The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
>     '-fx-background-color' for RichParagraph segment.
>
>     I've opened an issue today, so, when it is approved there won't be any questions.
>
>     Best regards, Pavel
>
>     On 5/6/25 00:04, Andy Goryachev wrote:
>
>         Will not happen.? CSS compatibility with a third party library is not a requirement in this case.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Monday, May 5, 2025 at 13:59
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>         To be as clear as possible, here's what I need:
>
>         .test {
>         -fx-set-somehow-background-color: green;
>         }
>
>         var builder = RichParagraph.builder();
>         builder.addWithStyleNames(segment, "test");
>
>         because, in parallel for RTFX I simply use its stylesheet:
>
>         .test {
>         ???? -rtfx-background-color: green;
>         }
>
>
>         So, for both code areas, I use same style classes for styling paragraph segments.
>
>         Best regards, Pavel
>
>         On 5/5/25 23:20, Andy Goryachev wrote:
>
>             Right, the API are missing currently.? I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.? Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well. Right?
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Monday, May 5, 2025 at 13:10
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>             Andy, thank you very much for your help.
>
>             That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
>             and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.
>
>             Well, technically I could, but it just wouldn?t make any sense.
>
>             Best regards, Pavel
>
>             On 5/5/25 22:54, Andy Goryachev wrote:
>
>                 You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
>                 JDK-8355774 is pretty high on my list of things to do.
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Monday, May 5, 2025 at 12:47
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>                 Hello, Andy
>
>                 Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
>                 I have just opened an issue with ID : 9078469.
>
>                 Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
>                 that it's impossible to work without it.
>
>                 Best regards, Pavel
>
>                 On 5/5/25 22:09, Andy Goryachev wrote:
>
>                     Dear Pavel:
>
>                     Can you clarify what you are trying to do exactly?
>
>                     If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>                     If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS. There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>                     -andy
>
>                     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                     *Date: *Saturday, May 3, 2025 at 10:07
>                     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                     *Subject: *CodeArea: -fx-background-color doesn't work.
>
>                     For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>                     Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>                     Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>                     they?have?-rtfx-background-color.
>
>                     public?class?JfxCodeArea?extends?Application?{
>
>                     ?????@Override
>                     ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>                     ?????????String?text?=?"""
>                     ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>                     ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>                     ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>                     ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>                     ???????????????????????""";
>
>                     ?????????String?css?=?"""
>                     ?????????????.test?{
>                     ?????????????????-fx-font-weight:?bold;
>                     ?????????????????-fx-fill:?red;
>                     ?????????????????-fx-background-color:?green;
>                     ?????????????}
>
>                     ?????????""";
>                     ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>                     ?????????CodeArea?codeArea?=?new?CodeArea();
>                     ?????????codeArea.getStylesheets().add(data);
>
>                     ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>                     ?????????????@Override
>                     ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>                     ?????????????????var?builder?=?RichParagraph.builder();
>                     ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>                     ?????????????????return?builder.build();
>                     ?????????????}
>
>                     ?????????????@Override
>                     ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>                     ?????????????}
>                     ?????????});
>
>                     ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>                     ?????????var?button?=?new?Button("Go!");
>                     ?????????button.setOnAction(e?->?codeArea.setText(text));
>                     ?????????VBox?root?=?new?VBox(codeArea,?button);
>                     ?????????Scene?scene?=?new?Scene(root,?600,?200);
>                     ?????????primaryStage.setScene(scene);
>                     ?????????primaryStage.show();
>
>                     ?????}
>
>                     ?????public?static?void?main(String[]?args)?{
>                     ?????????launch(args);
>                     ?????}
>                     }
>
>                     Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250507/1f3e558e/attachment-0001.htm>

From tsayao at openjdk.org  Wed May  7 18:53:57 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 18:53:57 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <3GX2phXtO0jM1eYtPYoB20SmbOsx4UgDRPDe7_0OlPM=.5c2c9153-83b8-4ade-bf40-34314aa54ebd@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <3GX2phXtO0jM1eYtPYoB20SmbOsx4UgDRPDe7_0OlPM=.5c2c9153-83b8-4ade-bf40-34314aa54ebd@github.com>
Message-ID: <D2PVhXqqA04agVcbqqlKaqznZqQuSh-rnedl5CIne48=.1faf7e0e-c4c6-4781-b18a-30164fbbe545@github.com>

On Wed, 7 May 2025 14:00:28 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> I think the GTK changes are fine, however the tests need some addressing.
> 
> On Linux (Ubuntu 24.04.2 VM) I see consistently failing two tests:
> 
> ```
>     StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [1] DECORATED
>     StageOwnershipTest. testClosingAppModalShouldFocusParent(StageStyle) [2] UNDECORATED
> ```
> 
> Not sure for the reason for these, but it is a similar failure to Windows ones listed below - line 436 `assertTrue(stage1.isFocused())` fails.
> 

This is because the focus stealing prevention mechanism on gnome/mutter. It's a sensitive topic in the gnome community, with lovers and haters :)

I still have to fix it - it's on my list.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2859884221

From andy.goryachev at oracle.com  Wed May  7 19:14:10 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 May 2025 19:14:10 +0000
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <fa95547c-f53f-4141-8c4d-855a5f6e4422@gmail.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
 <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>
 <BYAPR10MB3013772564627E93FB27059AE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <fa95547c-f53f-4141-8c4d-855a5f6e4422@gmail.com>
Message-ID: <BYAPR10MB301389C6BCDB11A7A5E6A4D8E588A@BYAPR10MB3013.namprd10.prod.outlook.com>

> Could you please confirm whether RichParagraph.Builder.addWithStyleNames(String text, String... css) can also be used for background coloring?

No, it cannot.  This (and other methods that add a text segment), while adding the style names to the underlying nodes, cannot style the background.  The reason is these methods add the Text instances, and the Text class does not have the background property.  So even if your CSS style specifies the background properties, they will be ignored.

The highlights, on the other hand, are special shapes placed behind the text nodes, and these can be styled with background (though the corresponding public APIs are missing, JDK-8355774).  Same applies to wavy lines.

I'll try to clarify these points in https://bugs.openjdk.org/browse/JDK-8355774

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 11:54
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
I've read your comments on the issue and was actually in the process of writing to you when I received your message.
Let me clarify a critically important point.

Currently, to style segment text using CSS style classes, we use this method:
RichParagraph.Builder.addWithStyleNames(String text, String... css) - ONE METHOD FOR ALL STYLE CLASSES.

If I understand correctly (and I might be wrong!), you're suggesting using a DIFFERENT method for background color styling:
RichParagraph.Builder#addHighlight(int start, int end, String... styles).

Could you please confirm whether RichParagraph.Builder.addWithStyleNames(String text, String... css) can also be used for background coloring?

For example, we know that user wants to add style classes "foo" and "bar" to a text from from 5 to 20. We do not know IF THESE STYLES
SET BACKGROUND COLOR. Or should we ask an user to name a class this way - "foo-bg"?

Best regards, Pavel
On 5/7/25 21:16, Andy Goryachev wrote:
Thank you for the feedback!

I finally got the ticket - https://bugs.openjdk.org/browse/JDK-8356436 .  It's a dup of https://bugs.openjdk.org/browse/JDK-8355774 , essentially.  Once the missing APIs are added, you'll be able to style the highlights with CSS:

RichParagraph.Builder#addHighlight(int start, int length, String ... css)

-andy

P.S.  In some of your code, you do css.toArray() for each paragraph.  I wonder if you should just create a bunch of styles statically instead - like a document stylesheet, since these names do not change at all.




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 10:30
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help!

Best regards, Pavel
On 5/7/25 20:29, Andy Goryachev wrote:
This bug is still percolating through the system.  I'll respond once I get it.

Thank you for all the questions and the feedback!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 14:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
'-fx-background-color' for RichParagraph segment.

I've opened an issue today, so, when it is approved there won't be any questions.

Best regards, Pavel
On 5/6/25 00:04, Andy Goryachev wrote:
Will not happen.  CSS compatibility with a third party library is not a requirement in this case.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:59
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
To be as clear as possible, here's what I need:

.test {
     -fx-set-somehow-background-color: green;
}

var builder = RichParagraph.builder();
builder.addWithStyleNames(segment, "test");

because, in parallel for RTFX I simply use its stylesheet:

.test {
     -rtfx-background-color: green;
}


So, for both code areas, I use same style classes for styling paragraph segments.

Best regards, Pavel
On 5/5/25 23:20, Andy Goryachev wrote:
Right, the API are missing currently.  I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.  Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well.  Right?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 13:10
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Andy, thank you very much for your help.

That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.

Well, technically I could, but it just wouldn?t make any sense.

Best regards, Pavel
On 5/5/25 22:54, Andy Goryachev wrote:
You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.

JDK-8355774 is pretty high on my list of things to do.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 5, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: CodeArea: -fx-background-color doesn't work.
Hello, Andy

Yes, I need to add a background color for a text segment within a paragraph using CSS.

I have just opened an issue with ID : 9078469.

Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
that it's impossible to work without it.

Best regards, Pavel
On 5/5/25 22:09, Andy Goryachev wrote:
Dear Pavel:

Can you clarify what you are trying to do exactly?

If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().

If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS.  There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Saturday, May 3, 2025 at 10:07
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: -fx-background-color doesn't work.
For styling CodeArea, I use exclusively style classes, and this is the foundation of my entire architecture.
Today I tried to implement search highlighting (via background color), but it didn't work. Below is my test code.

Can anyone tell me how to set the background color using CSS? For example, in RichTextFX's CodeArea,
they have -rtfx-background-color.

public class JfxCodeArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         String text = """
                       Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
                       ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco
                       laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
                       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
                       """;

         String css = """
             .test {
                 -fx-font-weight: bold;
                 -fx-fill: red;
                 -fx-background-color: green;
             }

         """;
         String data = "data:text/css;base64," + Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));

         CodeArea codeArea = new CodeArea();
         codeArea.getStylesheets().add(data);

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 var builder = RichParagraph.builder();
                 builder.addWithStyleNames(model.getPlainText(index), "test");
                 return builder.build();
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop, int linesAdded, int charsBottom) {

             }
         });

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         var button = new Button("Go!");
         button.setOnAction(e -> codeArea.setText(text));
         VBox root = new VBox(codeArea, button);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

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

Best regards, Pavel






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

From mfox at openjdk.org  Wed May  7 19:52:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 7 May 2025 19:52:58 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
 <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>
Message-ID: <LzCrUfxy8DGXhWWZFCe_4WCKBEL_ks1p7r-A6zV7zqk=.7223b29c-263d-4ccf-86a5-67195f90200c@github.com>

On Wed, 7 May 2025 18:45:37 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 436:
>> 
>>> 434:                 stage2::show,
>>> 435:                 stage2::close,
>>> 436:                 () -> assertTrue(stage1.isFocused()));
>> 
>> This test looks incorrect. If closing an app modal window should focus the parent (and I think it should) then stage0 should be focused.
>
> But `stage1` is the owner of `stage2`

When stage2 is created you pass in stage0 as the owner, not stage1.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2078371628

From tsayao at openjdk.org  Wed May  7 20:38:58 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 7 May 2025 20:38:58 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <LzCrUfxy8DGXhWWZFCe_4WCKBEL_ks1p7r-A6zV7zqk=.7223b29c-263d-4ccf-86a5-67195f90200c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
 <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>
 <LzCrUfxy8DGXhWWZFCe_4WCKBEL_ks1p7r-A6zV7zqk=.7223b29c-263d-4ccf-86a5-67195f90200c@github.com>
Message-ID: <-e3004pK5tFoHDR7S3hjMZPsMJT_eeBZbdqmJKM3kwM=.3f338f03-26d1-4f7e-ae63-73a3537127df@github.com>

On Wed, 7 May 2025 19:50:25 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> But `stage1` is the owner of `stage2`
>
> When stage2 is created you pass in stage0 as the owner, not stage1.

Sorry, my bad, you're right. I now hide in shame..

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2078453995

From kizune at openjdk.org  Wed May  7 22:01:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 7 May 2025 22:01:56 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H954rP-CXYQ2cGuPIu-CbteMeuaslWqphYKanpo3AJc=.de5f058b-1562-45c4-aa52-c62ba7c7f66f@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
 <H954rP-CXYQ2cGuPIu-CbteMeuaslWqphYKanpo3AJc=.de5f058b-1562-45c4-aa52-c62ba7c7f66f@github.com>
Message-ID: <BSoarnKof3Xhm7dafwz54uX66bFmE6qqe5FBUlzItmw=.e944a51c-0bea-467c-9296-f8c000a0ed79@github.com>

On Wed, 7 May 2025 15:43:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> so the group protocol is **not** needed for the progress bar/indicator?

What? It is required see the definition for the interface:
`@interface JFXProgressIndicatorAccessibility :
        JFXGroupAccessibility<NSAccessibilityProgressIndicator>`

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2860488987

From angorya at openjdk.org  Wed May  7 22:04:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 22:04:58 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
Message-ID: <6nw87xOegH6dE_QHYV-twK59qVtGTVMb3g3NxvCgVW4=.bbc35272-9ce0-4b2d-b50f-b3cb85375b17@github.com>

On Wed, 7 May 2025 15:42:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Added newlines where they were missing;
>   - Removed ebug output;
>   - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

Marked as reviewed by angorya (Reviewer).

oops, my mistake: I thought the group was removed somehow...  all good now.

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

PR Review: https://git.openjdk.org/jfx/pull/1796#pullrequestreview-2823306372
PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2860493657

From pavelturk2000 at gmail.com  Wed May  7 22:48:04 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 8 May 2025 01:48:04 +0300
Subject: CodeArea: -fx-background-color doesn't work.
In-Reply-To: <BYAPR10MB301389C6BCDB11A7A5E6A4D8E588A@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <2609126f-f5a6-466c-89b3-05ff54281d2c@gmail.com>
 <BYAPR10MB301337BF68C158E7D687E9F8E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8a183330-203a-4e90-b7f1-2fc999afd1eb@gmail.com>
 <BYAPR10MB3013C01179A1F8CA9244D137E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <899a6afd-90c1-44fa-a0a2-09671a894671@gmail.com>
 <BYAPR10MB30134BFC673C3564439281FBE58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <2bcd36da-3780-4348-a4e2-0bea7fa8e986@gmail.com>
 <BYAPR10MB30139EE5AA704C16D51AD060E58E2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <10a8868d-ecac-420c-a2c2-0e1983193010@gmail.com>
 <BYAPR10MB30139275119C1CD9D8ACB86DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c83ed477-e02f-4574-9b48-a784a0d3e284@gmail.com>
 <BYAPR10MB3013772564627E93FB27059AE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <fa95547c-f53f-4141-8c4d-855a5f6e4422@gmail.com>
 <BYAPR10MB301389C6BCDB11A7A5E6A4D8E588A@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <212682c3-8bc0-4c7e-b906-3cd94e7f75de@gmail.com>

Andy, thank you for such a detailed reply.

Unfortunately, I believe this direction is misguided and should be avoided. That?s why I?ve added further information to JDK-8356436.

Best regards, Pavel

On 5/7/25 22:14, Andy Goryachev wrote:
>
> > Could you please confirm whether RichParagraph.Builder.addWithStyleNames(String text, String... css) can also be used for background coloring?
>
> No, it cannot.? This (and other methods that add a text segment), while adding the style names to the underlying nodes, cannot style the background.? The reason is these methods add the Text instances, and the Text class does not have the background property.? So even if your CSS style specifies the background properties, they will be ignored.
>
> The highlights, on the other hand, are special shapes placed behind the text nodes, and these can be styled with background (though the corresponding public APIs are missing, JDK-8355774).? Same applies to wavy lines.
>
> I'll try to clarify these points in https://bugs.openjdk.org/browse/JDK-8355774
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, May 7, 2025 at 11:54
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
> I've read your comments on the issue and was actually in the process of writing to you when I received your message.
> Let me clarify a critically important point.
>
> Currently, to style segment text using CSS style classes, we use this method:
> RichParagraph.Builder.addWithStyleNames(String text, String... css) - ONE METHOD FOR ALL STYLE CLASSES.
>
> If I understand correctly (and I might be wrong!), you're suggesting using a DIFFERENT method for background color styling:
> RichParagraph.Builder#addHighlight(int start, int end, String... styles).
>
> Could you please confirm whether RichParagraph.Builder.addWithStyleNames(String text, String... css) can also be used for background coloring?
>
> For example, we know that user wants to add style classes "foo" and "bar" to a text from from 5 to 20. We do not know IF THESE STYLES
> SET BACKGROUND COLOR. Or should we ask an user to name a class this way - "foo-bg"?
>
> Best regards, Pavel
>
> On 5/7/25 21:16, Andy Goryachev wrote:
>
>     Thank /you/ for the feedback!
>
>     I finally got the ticket - https://bugs.openjdk.org/browse/JDK-8356436 .? It's a dup of https://bugs.openjdk.org/browse/JDK-8355774 , essentially.? Once the missing APIs are added, you'll be able to style the highlights with CSS:
>
>     RichParagraph.Builder#addHighlight(int start, int length, String ... css)
>
>     -andy
>
>     P.S. In some of your code, you do css.toArray() for each paragraph.? I wonder if you should just create a bunch of styles statically instead - like a document stylesheet, since these names do not change at all.
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Wednesday, May 7, 2025 at 10:30
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>     Andy, thank you very much for your help!
>
>     Best regards, Pavel
>
>     On 5/7/25 20:29, Andy Goryachev wrote:
>
>         This bug is still percolating through the system.? I'll respond once I get it.
>
>         Thank you for all the questions and the feedback!
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Monday, May 5, 2025 at 14:13
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>         No, I am afraid you misunderstood me. I am not talking about compatibility with a third party library.
>         The "compatibility" already exists and its name is CSS. So, the only thing I need is to support
>         '-fx-background-color' for RichParagraph segment.
>
>         I've opened an issue today, so, when it is approved there won't be any questions.
>
>         Best regards, Pavel
>
>         On 5/6/25 00:04, Andy Goryachev wrote:
>
>             Will not happen.? CSS compatibility with a third party library is not a requirement in this case.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Monday, May 5, 2025 at 13:59
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>             To be as clear as possible, here's what I need:
>
>             .test {
>             -fx-set-somehow-background-color: green;
>             }
>
>             var builder = RichParagraph.builder();
>             builder.addWithStyleNames(segment, "test");
>
>             because, in parallel for RTFX I simply use its stylesheet:
>
>             .test {
>             -rtfx-background-color: green;
>             }
>
>
>             So, for both code areas, I use same style classes for styling paragraph segments.
>
>             Best regards, Pavel
>
>             On 5/5/25 23:20, Andy Goryachev wrote:
>
>                 Right, the API are missing currently.? I just point out the fact that you must use highlights for the purpose of highlighting text range(s) within the paragraph, since these ranges might contain semi-transparent Nodes.? Once JDK-8355774 is fixed you'll be able to style highlights with CSS and all will be well. Right?
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Monday, May 5, 2025 at 13:10
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>                 Andy, thank you very much for your help.
>
>                 That doesn?t work for me. As I mentioned before, I?m working with two CodeArea implementations - JFX and RTFX,
>                 and CSS is the common styling mechanism. I can?t use code for one and CSS for the other.
>
>                 Well, technically I could, but it just wouldn?t make any sense.
>
>                 Best regards, Pavel
>
>                 On 5/5/25 22:54, Andy Goryachev wrote:
>
>                     You have to use highlights for that, since you can't assign CSS style to a part of the Text instance, and you can't set a background on it.
>
>                     JDK-8355774 is pretty high on my list of things to do.
>
>                     -andy
>
>                     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                     *Date: *Monday, May 5, 2025 at 12:47
>                     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                     *Subject: *Re: CodeArea: -fx-background-color doesn't work.
>
>                     Hello, Andy
>
>                     Yes, I need to add a background color for a text segment within a paragraph using CSS.
>
>                     I have just opened an issue with ID : 9078469.
>
>                     Can anyone give an estimate of when this issue might be addressed? Background color is such a fundamental feature
>                     that it's impossible to work without it.
>
>                     Best regards, Pavel
>
>                     On 5/5/25 22:09, Andy Goryachev wrote:
>
>                         Dear Pavel:
>
>                         Can you clarify what you are trying to do exactly?
>
>                         If you are trying to add a background to a text segment within the paragraph (as your code seem to indicate), then the only way to do it is to call Builder.addHighlight().
>
>                         If you are trying to set the background of the whole paragraph, you've hit another missing API similar to JDK-8355774 - there is currently no way to style the paragraphs via CSS. There is the Builder.setParagraphAttributes(StyleAttributeMap) but a CSS one is missing.
>
>                         -andy
>
>                         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                         *Date: *Saturday, May 3, 2025 at 10:07
>                         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                         *Subject: *CodeArea: -fx-background-color doesn't work.
>
>                         For?styling?CodeArea,?I?use?exclusively?style?classes,?and?this?is?the?foundation?of?my?entire?architecture.
>                         Today?I?tried?to?implement?search?highlighting?(via?background?color),?but?it?didn't?work.?Below?is?my?test?code.
>
>                         Can?anyone?tell?me?how?to?set?the?background?color?using?CSS??For?example,?in?RichTextFX's?CodeArea,
>                         they?have?-rtfx-background-color.
>
>                         public?class?JfxCodeArea?extends?Application?{
>
>                         ?????@Override
>                         ?????public?void?start(Stage?primaryStage)?throws?Exception?{
>                         ?????????String?text?=?"""
>                         ???????????????????????Lorem?ipsum?dolor?sit?amet,?consectetur?adipiscing?elit,?sed?do?eiusmod?tempor?incididunt
>                         ???????????????????????ut?labore?et?dolore?magna?aliqua.?Ut?enim?ad?minim?veniam,?quis?nostrud?exercitation?ullamco
>                         ???????????????????????laboris?nisi?ut?aliquip?ex?ea?commodo?consequat.?Duis?aute?irure?dolor?in?reprehenderit
>                         ???????????????????????in?voluptate?velit?esse?cillum?dolore?eu?fugiat?nulla?pariatur.
>                         ???????????????????????""";
>
>                         ?????????String?css?=?"""
>                         ?????????????.test?{
>                         ?????????????????-fx-font-weight:?bold;
>                         ?????????????????-fx-fill:?red;
>                         ?????????????????-fx-background-color:?green;
>                         ?????????????}
>
>                         ?????????""";
>                         ?????????String?data?= "data:text/css;base64,"?+?Base64.getEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8));
>
>                         ?????????CodeArea?codeArea?=?new?CodeArea();
>                         ?????????codeArea.getStylesheets().add(data);
>
>                         ?????????codeArea.setSyntaxDecorator(new?SyntaxDecorator()?{
>                         ?????????????@Override
>                         ?????????????public?RichParagraph?createRichParagraph(CodeTextModel?model,?int?index)?{
>                         ?????????????????var?builder?=?RichParagraph.builder();
>                         ?????????????????builder.addWithStyleNames(model.getPlainText(index),?"test");
>                         ?????????????????return?builder.build();
>                         ?????????????}
>
>                         ?????????????@Override
>                         ?????????????public?void?handleChange(CodeTextModel?m,?TextPos?start,?TextPos?end,?int?charsTop,?int?linesAdded,?int?charsBottom)?{
>
>                         ?????????????}
>                         ?????????});
>
>                         ?????????VBox.setVgrow(codeArea,?Priority.ALWAYS);
>                         ?????????var?button?=?new?Button("Go!");
>                         ?????????button.setOnAction(e?->?codeArea.setText(text));
>                         ?????????VBox?root?=?new?VBox(codeArea,?button);
>                         ?????????Scene?scene?=?new?Scene(root,?600,?200);
>                         ?????????primaryStage.setScene(scene);
>                         ?????????primaryStage.show();
>
>                         ?????}
>
>                         ?????public?static?void?main(String[]?args)?{
>                         ?????????launch(args);
>                         ?????}
>                         }
>
>                         Best?regards,?Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250508/907e8dd9/attachment-0001.htm>

From angorya at openjdk.org  Wed May  7 23:12:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 May 2025 23:12:55 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v2]
In-Reply-To: <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>
Message-ID: <uG49ZLrNDnTPyRkXbjK14lxDYqfH8Wro81uthSiyOy8=.e9dff5b9-560c-4685-a12c-607dbbbfdd03@github.com>

On Wed, 7 May 2025 15:56:57 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TreeCellSkin.java

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 226:

> 224: 
> 225:                     final VirtualFlow<?> flow = getVirtualFlow();
> 226:                     for (IndexedCell cell : flow.cells) {

`getVirtualFlow()` might return null, right?

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 261:

> 259:         Parent p = getSkinnable();
> 260:         while (p != null) {
> 261:             if (p instanceof VirtualFlow) {

can be simplified:


if (p instanceof VirtualFlow vf) {
  return vf;

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2078623155
PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2078622098

From mstrauss at openjdk.org  Thu May  8 10:19:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 May 2025 10:19:06 GMT
Subject: RFR: 8345348: CSS media feature queries [v23]
In-Reply-To: <hz98cSp5pz4BMhf-0knYM1BG9rdSt1XjJK4bVzbE_ys=.b1ebc8fd-58e5-467e-afc9-725df2e5dca2@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <L_llITfF59OQ9CsOI8C3KTG3twj8CJ1dFj-bBMLPtE0=.29434dc8-39ae-4ea7-a4bc-12f94f52c29f@github.com>
 <wjH0ckFpHfmzNRTibf3w390bwmh8ZVSmQVQvLF27l70=.5756582c-4dbf-4330-8df3-44bd167067c0@github.com>
 <D29sOD78XRSZPD43l8PyEUyn--6Z3k6pkiiWzgIz_80=.b600f918-ad39-4fb3-8902-34ac8a62d9b9@github.com>
 <Y3qZ2Xu3b0DrWoFm3WBQzzsCY9BFAJOyl66ez1ZlJjQ=.1a8aebd8-7e01-4303-85f5-b9e2c9013d9e@github.com>
 <rvq_a2NmXq1oBEy347bylOWY5gyrRN4mITgWHM9yUlM=.cd52532a-50e5-4ce8-bc1d-550cfec9a28f@github.com>
 <9odGuwhmmYZGX9XtqZsb-1IMMiDtWQpPlKj7ITE46Xk=.d037485e-1129-4396-864c-193b8ba43776@github.com>
 <v8o2hYoS_jWg_G91dicx3ZPBowgW_tvJ7KVfnb6YyWA=.ebf6e000-1f11-4b8c-8ed4-ad92e872df77@github.com>
 <j18DbuGlSMBZVwXKi-1_ui2v9lUPH1H7xckGKu0a5eo=.84d06e64-747a-45ac-8430-ecff0392c1f1@github.com>
 <5K_bSLMRTpwRyGo_8ysgZx5fEGtzQaWOgVjbZq8IsjM=.35e9516e-f99b-4f25-bceb-d5156c1b8d6a@github.com>
 <-WQOYjleZPWNHvWxyJwvmc8c9TmPJYEAh6i
 AfZu06E0=.a9d95212-f28e-4f73-b0b9-e2d524f126e4@github.com>
 <hz98cSp5pz4BMhf-0knYM1BG9rdSt1XjJK4bVzbE_ys=.b1ebc8fd-58e5-467e-afc9-725df2e5dca2@github.com>
Message-ID: <8t9_NX6E6KKcqaM7ULOvOlGXTjQRELG0GXqyGy5lMIQ=.071a5f19-0149-45d6-966e-3c8a2cd4c605@github.com>

On Wed, 7 May 2025 15:24:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Further, if you call `setAccessibile` in connection with `--add-opens`, which your above code snippet does, you can even call _private_ methods.
>> 
>> So at the risk of repeating myself, there is no concern that making this method public exposes it to applications. However, making it package-scope if it doesn't need to be public, is a best practice if it doesn't need to be accessed outside the package.
>
> yes, I agree - thanks for the discussion!
> 
> (and `setAccessible()` is not needed with `--add-opens`)
> 
> I withdraw my comments - making these methods `private` is not needed, `public` or package-scope is fine.

> So at the risk of repeating myself, there is no concern that making this method public exposes it to applications. However, making it package-scope if it doesn't need to be public, is a best practice if it doesn't need to be accessed outside the package.

These methods can have any visibility and it doesn't change their semantics at all, because the methods are declared in a private nested class (so they are not visible outside of the enclosing class). As a reminder, the enclosing class has access even to private members of its nested classes. The reason I chose to make the methods public is merely to indicate "this is supposed to be public API for the enclosing class".

I'm not inclined to change that, as all of the arguments presented so far do not apply. The methods are not visible in other top-level classes (even in the same package), and making them any less visible doesn't change that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2079422989

From zelmidaoui at openjdk.org  Thu May  8 14:59:40 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 8 May 2025 14:59:40 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v3]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <wCR262i7dAwTEnlaD0MO3noUz85fKBrsD54Uzechyks=.39132b42-b918-438e-b142-b4f13b209879@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Fixed minor issues and added test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/a07148a2..6ae2f74b

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

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

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

From zelmidaoui at openjdk.org  Thu May  8 14:59:40 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 8 May 2025 14:59:40 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v2]
In-Reply-To: <uG49ZLrNDnTPyRkXbjK14lxDYqfH8Wro81uthSiyOy8=.e9dff5b9-560c-4685-a12c-607dbbbfdd03@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>
 <uG49ZLrNDnTPyRkXbjK14lxDYqfH8Wro81uthSiyOy8=.e9dff5b9-560c-4685-a12c-607dbbbfdd03@github.com>
Message-ID: <PeXLW6T3-7EaqffVjLUorXwrunqAZOsLdk8xCk-ycHs=.04004aef-358b-4132-907f-d0b057596d2f@github.com>

On Wed, 7 May 2025 23:09:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TreeCellSkin.java
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 226:
> 
>> 224: 
>> 225:                     final VirtualFlow<?> flow = getVirtualFlow();
>> 226:                     for (IndexedCell cell : flow.cells) {
> 
> `getVirtualFlow()` might return null, right?

Yes,
I added a check for null value

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 261:
> 
>> 259:         Parent p = getSkinnable();
>> 260:         while (p != null) {
>> 261:             if (p instanceof VirtualFlow) {
> 
> can be simplified:
> 
> 
> if (p instanceof VirtualFlow vf) {
>   return vf;

I made the change , thanks

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2079888335
PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2079888974

From angorya at openjdk.org  Thu May  8 15:11:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 May 2025 15:11:10 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v3]
In-Reply-To: <wCR262i7dAwTEnlaD0MO3noUz85fKBrsD54Uzechyks=.39132b42-b918-438e-b142-b4f13b209879@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <wCR262i7dAwTEnlaD0MO3noUz85fKBrsD54Uzechyks=.39132b42-b918-438e-b142-b4f13b209879@github.com>
Message-ID: <ewohkUHiyTYShJLQAYETwORsWoOA41L372Aszkg9TuY=.03ac4fd7-6b16-407f-8dd5-85769047b6f8@github.com>

On Thu, 8 May 2025 14:59:40 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issues and added test

Good job figuring out the fix and coming up with a test!

- the reproducer in the ticket works correctly after the fix
- the test fails in the master and passes with the fix

left some minor comments, but I think it is in a very good shape.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 4120:

> 4118:         for (Map.Entry<String, Double> entry : layoutXMap.entrySet()) {
> 4119:             double x = entry.getValue();
> 4120:             assertEquals(first, x, "Alignment mismatch for item: " + entry.getKey());

typically when we compare results of a floating point computation, we should not use exact comparison, due to accumulation of small errors stemming from inexact nature of floating point values.  the amount of allowed difference depends on the magnitude of values and a number of operations.  we usually throw 1e-6 or something like that.

it might be ok here, because the computation goes through the same path and same values each time.

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

PR Review: https://git.openjdk.org/jfx/pull/1715#pullrequestreview-2825387702
PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2079906716

From angorya at openjdk.org  Thu May  8 15:11:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 May 2025 15:11:12 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v2]
In-Reply-To: <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <5fJcRW34ZWMft9UYQAMfoigxzV9dYkOmmN3LeQ60F_s=.64b9b20c-139d-4e60-b727-f5ef1fefe90e@github.com>
Message-ID: <cAehkJk0r8vhqkruRIxvJaiJzAnoHYGqCgG5uCyU1Ns=.a3e813d2-3ccf-43cc-96ee-b249934d9b84@github.com>

On Wed, 7 May 2025 15:56:57 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TreeCellSkin.java

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 225:

> 223:                     maxDisclosureWidthMap.put(tree, disclosureWidth);
> 224: 
> 225:                     final VirtualFlow<?> flow = getVirtualFlow();

`final` is not necessary here

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 227:

> 225:                     final VirtualFlow<?> flow = getVirtualFlow();
> 226:                     for (IndexedCell cell : flow.cells) {
> 227:                         if (cell == null || cell.isEmpty()) continue;

minor: it might be better to place continue in a separate block surrounded by curly braces:

if (x) {
  continue;
}


alternatively, it can be made even clearer:

if (cell != null && !cell.isEmpty()) {
                        cell.requestLayout();
                        cell.layout();
}

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2079863305
PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2079871343

From zelmidaoui at openjdk.org  Thu May  8 16:04:05 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 8 May 2025 16:04:05 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v3]
In-Reply-To: <ewohkUHiyTYShJLQAYETwORsWoOA41L372Aszkg9TuY=.03ac4fd7-6b16-407f-8dd5-85769047b6f8@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <wCR262i7dAwTEnlaD0MO3noUz85fKBrsD54Uzechyks=.39132b42-b918-438e-b142-b4f13b209879@github.com>
 <ewohkUHiyTYShJLQAYETwORsWoOA41L372Aszkg9TuY=.03ac4fd7-6b16-407f-8dd5-85769047b6f8@github.com>
Message-ID: <P6O6_wrUw4SVoj_CWyZk6tCtrf-Nb_bHuwrk9P9wSJo=.4440645d-a453-4951-b14c-f3688bb702ce@github.com>

On Thu, 8 May 2025 15:03:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed minor issues and added test
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 4120:
> 
>> 4118:         for (Map.Entry<String, Double> entry : layoutXMap.entrySet()) {
>> 4119:             double x = entry.getValue();
>> 4120:             assertEquals(first, x, "Alignment mismatch for item: " + entry.getKey());
> 
> typically when we compare results of a floating point computation, we should not use exact comparison, due to accumulation of small errors stemming from inexact nature of floating point values.  the amount of allowed difference depends on the magnitude of values and a number of operations.  we usually throw 1e-6 or something like that.
> 
> it might be ok here, because the computation goes through the same path and same values each time.

that's true, I did use it at first with a tolerance of 0.01 which is minimal and it didn't make a difference in this test since it's not some complex test case. 
But I will add it and use 1e-6.
`assertEquals(first, x, 1e-6, "Alignment mismatch for item: " + entry.getKey());`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2080018133

From angorya at openjdk.org  Thu May  8 17:46:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 May 2025 17:46:09 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
Message-ID: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@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) {

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

Commit messages:
 - tab
 - css

Changes: https://git.openjdk.org/jfx/pull/1802/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355774
  Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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 angorya at openjdk.org  Thu May  8 17:47:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 May 2025 17:47:46 GMT
Subject: RFR: 8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible
 [v2]
In-Reply-To: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
References: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
Message-ID: <U08OQWlgiM2ROkXqhh5qvrZJbr3IZhWui6IPzNKpZws=.d0e05570-a689-4a7f-a910-904d4a9ba155@github.com>

> Fixed an NPE that should only happen in a headless test environment.
> 
> This is a follow-up for https://github.com/openjdk/jfx/pull/1677

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 remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
 - on windows
 - Merge remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
 - npe

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1793/files
  - new: https://git.openjdk.org/jfx/pull/1793/files/4dc2ad46..3109fb45

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

  Stats: 196 lines in 11 files changed: 169 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1793.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1793/head:pull/1793

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

From pavelturk2000 at gmail.com  Thu May  8 18:03:42 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 8 May 2025 21:03:42 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
Message-ID: <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>

I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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 andy.goryachev at oracle.com  Thu May  8 18:25:18 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 8 May 2025 18:25:18 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
Message-ID: <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>

Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250508/47480c84/attachment-0001.htm>

From pavelturk2000 at gmail.com  Thu May  8 18:44:35 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 8 May 2025 21:44:35 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>

Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
 ??? -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
 ??? -fx-fill: orange;
 ??? -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel

On 5/8/25 21:25, Andy Goryachev wrote:
>
> Pavel:
>
> I think your comments in the ticket are still invisible to me, so I can't comment.
>
> About your recent comment in the PR - I have difficulty understanding what you mean.? We are not adding methods to "style individual properties".? We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
> Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 8, 2025 at 11:04
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
> methods for styling individual properties is a very problematic and dangerous decision.
>
> First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
> adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
> result wants to set background color for matches but another one wants to set foreground color + weight.
> Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
> be removed without breaking backward compatibility.
>
> I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
> by a moderator.
>
> When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
> which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
> This is my personal opinion, which, of course, can be wrong.
>
> Best regards, Pavel
>
> On 5/8/25 20:46, Andy Goryachev wrote:
> > 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) {
> >
> > -------------
> >
> > Commit messages:
> >?? - tab
> >?? - css
> >
> > Changes: https://git.openjdk.org/jfx/pull/1802/files
> >??? Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
> >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
> >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250508/9adee6b5/attachment-0001.htm>

From andy.goryachev at oracle.com  Thu May  8 19:21:50 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 8 May 2025 19:21:50 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
Message-ID: <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>

Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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

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

From pavelturk2000 at gmail.com  Thu May  8 20:12:53 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 8 May 2025 23:12:53 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>

Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel

On 5/8/25 22:21, Andy Goryachev wrote:
>
> Oh, I finally get it what you want.? Thanks!
>
> What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).? My first question is - what are the additional properties, beside the background-color?? If it's only the background color, it's probably easy to add.
>
> Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 8, 2025 at 11:44
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Andy, thank you for your reply.
>
> I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
> I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
> how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
> CSS file, there is a class:
>
> .search-match {
> ??? -fx-background-color: orange;
> }
>
> But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
> .search-match {
> ??? -fx-fill: orange;
> ??? -fx-font-weight: bold;
> }
>
> And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
> If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
> such as -fx-highlight-color. However, everything else in the example should work as described.
>
> Best regards, Pavel
>
> On 5/8/25 21:25, Andy Goryachev wrote:
>
>     Pavel:
>
>     I think your comments in the ticket are still invisible to me, so I can't comment.
>
>     About your recent comment in the PR - I have difficulty understanding what you mean.? We are not adding methods to "style individual properties".? We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>     Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Thursday, May 8, 2025 at 11:04
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>     methods for styling individual properties is a very problematic and dangerous decision.
>
>     First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>     adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>     result wants to set background color for matches but another one wants to set foreground color + weight.
>     Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>     be removed without breaking backward compatibility.
>
>     I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>     by a moderator.
>
>     When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>     which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>     This is my personal opinion, which, of course, can be wrong.
>
>     Best regards, Pavel
>
>     On 5/8/25 20:46, Andy Goryachev wrote:
>     > 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) {
>     >
>     > -------------
>     >
>     > Commit messages:
>     >?? - tab
>     >?? - css
>     >
>     > Changes: https://git.openjdk.org/jfx/pull/1802/files
>     >??? Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>     >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>     >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250508/9a0669ee/attachment-0001.htm>

From zelmidaoui at openjdk.org  Thu May  8 20:16:12 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 8 May 2025 20:16:12 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v4]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <jb8qqyL7GlwbkwNVF0YPgVVwXIhehHViiT2pcqQUvQA=.e3780906-46f6-4034-a513-4d739322b224@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Fixed minor issue with test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/6ae2f74b..0108cf78

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

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

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

From angorya at openjdk.org  Thu May  8 20:43:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 May 2025 20:43:57 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v4]
In-Reply-To: <jb8qqyL7GlwbkwNVF0YPgVVwXIhehHViiT2pcqQUvQA=.e3780906-46f6-4034-a513-4d739322b224@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <jb8qqyL7GlwbkwNVF0YPgVVwXIhehHViiT2pcqQUvQA=.e3780906-46f6-4034-a513-4d739322b224@github.com>
Message-ID: <dUMeBQm2GtFm2urTdr0cQRpJQfvEGy8ae0yGQt4wxHE=.7a728130-263b-43e9-9d28-f73fee369137@github.com>

On Thu, 8 May 2025 20:16:12 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed minor issue with test

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 228:

> 226:                     if (flow != null) {
> 227:                         for (IndexedCell cell : flow.cells) {
> 228:                             if (cell != null || !cell.isEmpty()) {

it has to be `&&`

`if (cell != null && !cell.isEmpty()) {`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2080435561

From andy.goryachev at oracle.com  Thu May  8 21:09:23 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 8 May 2025 21:09:23 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
Message-ID: <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>

The only property that makes sense is the background color.  The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.  The highlights were designed specifically for the case to highlight the content range regardless of what is in it.

I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.

Thank you for your patience and good suggestions!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 13:13
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel
On 5/8/25 22:21, Andy Goryachev wrote:
Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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


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

From pavelturk2000 at gmail.com  Fri May  9 05:18:23 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Fri, 9 May 2025 08:18:23 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>

Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!

Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
that the internet is extremely popular today and that links in code are common practice, and so on.

Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
when styling is completely separated from logic.

So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
core properties are supported.

That's just my feedback ? the decision is, of course, yours :)

Best regards, Pavel

On 5/9/25 00:09, Andy Goryachev wrote:
>
> The only property that makes sense is the background color.? The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.? The highlights were designed specifically for the case to highlight the content range regardless of what is in it.
>
> I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.
>
> Thank you for your patience and good suggestions!
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 8, 2025 at 13:13
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Since we?re talking about code styling, I would highlight the following as the main properties:
> - foreground color (+)
> - background color (-)
> - font (weight, italic, size, name) (+)
> - underline (e.g. for links) (?)
> - wavy underline (e.g. for spelling) (-)
>
> I think these properties cover 99% of all the necessary properties for CodeArea.
> I used + and - to show what has already been implemented.
>
> Best regards, Pavel
>
> On 5/8/25 22:21, Andy Goryachev wrote:
>
>     Oh, I finally get it what you want.? Thanks!
>
>     What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).? My first question is - what are the additional properties, beside the background-color?? If it's only the background color, it's probably easy to add.
>
>     Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Thursday, May 8, 2025 at 11:44
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     Andy, thank you for your reply.
>
>     I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
>     I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
>     how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
>     CSS file, there is a class:
>
>     .search-match {
>     ??? -fx-background-color: orange;
>     }
>
>     But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
>     .search-match {
>     ??? -fx-fill: orange;
>     ??? -fx-font-weight: bold;
>     }
>
>     And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
>     If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
>     such as -fx-highlight-color. However, everything else in the example should work as described.
>
>     Best regards, Pavel
>
>     On 5/8/25 21:25, Andy Goryachev wrote:
>
>         Pavel:
>
>         I think your comments in the ticket are still invisible to me, so I can't comment.
>
>         About your recent comment in the PR - I have difficulty understanding what you mean. We are not adding methods to "style individual properties".? We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>         Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Thursday, May 8, 2025 at 11:04
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>         I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>         methods for styling individual properties is a very problematic and dangerous decision.
>
>         First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>         adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>         result wants to set background color for matches but another one wants to set foreground color + weight.
>         Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>         be removed without breaking backward compatibility.
>
>         I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>         by a moderator.
>
>         When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>         which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>         This is my personal opinion, which, of course, can be wrong.
>
>         Best regards, Pavel
>
>         On 5/8/25 20:46, Andy Goryachev wrote:
>         > 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) {
>         >
>         > -------------
>         >
>         > Commit messages:
>         >?? - tab
>         >?? - css
>         >
>         > Changes: https://git.openjdk.org/jfx/pull/1802/files
>         >??? Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>         >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>         >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250509/3e43b9e2/attachment-0001.htm>

From zelmidaoui at openjdk.org  Fri May  9 10:51:20 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 9 May 2025 10:51:20 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Update TreeCellSkin.java

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/0108cf78..d0c46b14

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

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

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

From mhanl at openjdk.org  Fri May  9 12:18:58 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 9 May 2025 12:18:58 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v3]
In-Reply-To: <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
Message-ID: <LH8cawRiM-Sh_1ULDhqKVd0KdwOTrD5NymJJBw3cFfE=.5d949134-d5c3-40f2-92c3-c1a25e6ca111@github.com>

On Mon, 28 Apr 2025 09:38:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR enables `javafx.swt` tests for:
>> - Windows
>> 
>> Disabled on:
>> - Linux, since some distros seems to have problems
>> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SWT_TEST default is false on MacOS

So after checking on MacOS, the following warning is printed right before it fails: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread`. After researching, it seems that there really is no other way than setting that flag.

I think we might wanna set it in a follow up and recheck, if it works?

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2866330039

From mfox at openjdk.org  Fri May  9 16:11:07 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 9 May 2025 16:11:07 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <_MY9D_7C2TlAlr63oWFden-TJILvCRA4Bby-ka5wruQ=.ead38b6a-f79e-4d49-a52d-f959db1b3d06@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

What can we do to get this PR moving again?

It looks like the call to `updateSceneState` is necessary. The scene state is tracking the iconified state of the window and needs to be update when the window leaves the iconified state (so `updateSceneState` should also be called when the window is maximized). Personally I think the EventHandler should also call `entireSceneNeedsRepaint`; it's the core code that stopped drawing to the window when it became iconified and so it should be the core that ask for a repaint when the window is de-iconified. But I would also be happy to update the Mac glass code to call `notifyRepaint` to match Windows and Linux.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2867109131

From kcr at openjdk.org  Fri May  9 19:34:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 May 2025 19:34:58 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <9JOdmVf5_3l-tiAsxH01CL2Yo2mp8yAr2JJZzilXx_0=.8540955c-d797-46ea-996b-5d9b6a2a79f6@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

In reading through all of the comments again, I think that the proposed solution, with the addition of `entireSceneNeedsRepaint`, is a reasonable one. The only other question I have is: Would it be possible to create an automated test that fails (on macOS at least) without the fix and passes on all platforms with the fix?

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2867696715

From kcr at openjdk.org  Fri May  9 19:37:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 May 2025 19:37:55 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v3]
In-Reply-To: <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
Message-ID: <Dj2Z4kyDSqz0iYB0EpIz-a4PfhSm_ZvzroQt2y7lOSs=.e2aa6b5e-6105-461e-b1d6-ef6598b61ab1@github.com>

On Mon, 28 Apr 2025 09:38:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR enables `javafx.swt` tests for:
>> - Windows
>> 
>> Disabled on:
>> - Linux, since some distros seems to have problems
>> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SWT_TEST default is false on MacOS

Can you file follow-up bugs (one each) for the failures on macOS and Linux? Then add a comment in `build.gradle` as to why we are skipping the SWT tests on those platforms.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2867702176

From kcr at openjdk.org  Fri May  9 19:44:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 May 2025 19:44:58 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <mIkNTgKo8D6znmCf4LnNo5ADJ-h9Y_9VpG398JrMpjE=.85d91804-6cf9-4533-b12b-460bc8b2c54a@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

The updated fix looks good. I verified that it works as expected.

I'll approve it early next week if no issues are found during testing.

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

PR Review: https://git.openjdk.org/jfx/pull/1755#pullrequestreview-2829502333

From kcr at openjdk.org  Fri May  9 20:15:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 May 2025 20:15:54 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread [v2]
In-Reply-To: <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
 <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
Message-ID: <7drZi39DMPZO85hAlBW2P5UiEGVdE5fkqM4aZslNzHc=.f208e251-2c27-47ee-805a-b5faa6d6a923@github.com>

On Fri, 2 May 2025 15:44:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
>> 
>> Also, ensure that the reverse process also happens in the FX application thread.
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8355615.menubar
>  - in fx thread
>  - install

Looks good. The test doesn't fail on my system even without the fix, but the race condition you are fixing has a narrow window, so that's OK.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1795#pullrequestreview-2829558872

From mfox at openjdk.org  Fri May  9 23:12:57 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 9 May 2025 23:12:57 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <noy76rkNFsl8wbgXYGsYEnhwCaSmfshN0sYPupBGkig=.9be1941b-c3d9-4549-9975-649652e79686@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

I'll work on creating an automated test for this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2868044100

From kevin.rushforth at oracle.com  Sat May 10 16:16:12 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 10 May 2025 09:16:12 -0700
Subject: Proposed schedule for JavaFX 25
Message-ID: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>

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 mhanl at openjdk.org  Sat May 10 22:41:38 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 10 May 2025 22:41:38 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v4]
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <jjXjM1qpLFg05HOB4Q-1VTCfTHo6xhqz0aigdzaZ8TU=.50f43f6b-ac51-4f99-b50c-a3a4913dd136@github.com>

> This PR enables `javafx.swt` tests for:
> - Windows
> 
> Disabled on:
> - Linux, since some distros seems to have problems
> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread`

Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jfx into 8169285-swt-tests
 - SWT_TEST default is false on Linux
 - SWT_TEST default is false on MacOS
 - 8169285: SWT tests should run with IS_FULL_TEST
 - 8169285: Re-enable javafx.swt tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1783/files
  - new: https://git.openjdk.org/jfx/pull/1783/files/eabc48a2..a0f0cb88

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

  Stats: 118179 lines in 231 files changed: 27243 ins; 50822 del; 40114 mod
  Patch: https://git.openjdk.org/jfx/pull/1783.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1783/head:pull/1783

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

From mhanl at openjdk.org  Sat May 10 22:55:12 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 10 May 2025 22:55:12 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v5]
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <db3bg2T3lewGUIBBo4e3HzCFISdhp5YW8yqoBrSPQ2U=.32e66ba0-01a9-4a3f-a34f-837f924beba2@github.com>

> This PR enables `javafx.swt` tests for:
> - Windows
> 
> Disabled on:
> - Linux, since some distros seems to have problems
> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread`

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  link JDK tickets

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1783/files
  - new: https://git.openjdk.org/jfx/pull/1783/files/a0f0cb88..158ac825

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

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

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

From mhanl at openjdk.org  Sat May 10 23:45:03 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 10 May 2025 23:45:03 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
Message-ID: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>

This PR bumps the JUnit version to 5.12.2.
Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.

Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
The mentioned deprecations do not affect us.

Interesting new features:
- Thread dumps on test timeouts
- Parameterized test validation improvements
- JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

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

Commit messages:
 - 8356690: Update JUnit to 5.12.2

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

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

From nlisker at gmail.com  Sun May 11 05:32:34 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 11 May 2025 08:32:34 +0300
Subject: JavaFX Presentation at JavaOne
Message-ID: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>

Just saw Kevin's JavaFX talk released on YT. Thanks Kevin!

https://www.youtube.com/watch?v=FxHbXY34iFQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250511/c64790c4/attachment.htm>

From thiago.sayao at gmail.com  Sun May 11 11:57:38 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 11 May 2025 08:57:38 -0300
Subject: JavaFX Presentation at JavaOne
In-Reply-To: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
References: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
Message-ID: <CAAP_wumjHE8Zu42sk586=Ut8n3HD=WsrbieemRnrj4d+DdJA4g@mail.gmail.com>

I enjoyed it. Thanks!


Em dom., 11 de mai. de 2025 ?s 04:59, Nir Lisker <nlisker at gmail.com>
escreveu:

> Just saw Kevin's JavaFX talk released on YT. Thanks Kevin!
>
> https://www.youtube.com/watch?v=FxHbXY34iFQ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250511/041f139c/attachment.htm>

From tsayao at openjdk.org  Sun May 11 12:14:15 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 11 May 2025 12:14:15 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v20]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <oOIOa5HQa2uvhchi-eQ783hdE7qLp4PRaUq2BWWnNZI=.542897be-13f9-4112-8a0b-89d2d65505a3@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Review fixes
  - Fix Focus
  - Improvements on TestStage to assist testing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/699ed85f..6bd054b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=18-19

  Stats: 436 lines in 6 files changed: 251 ins; 86 del; 99 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From thiago.sayao at gmail.com  Sun May 11 12:19:17 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 11 May 2025 09:19:17 -0300
Subject: JavaFX Presentation at JavaOne
In-Reply-To: <CAAP_wumjHE8Zu42sk586=Ut8n3HD=WsrbieemRnrj4d+DdJA4g@mail.gmail.com>
References: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
 <CAAP_wumjHE8Zu42sk586=Ut8n3HD=WsrbieemRnrj4d+DdJA4g@mail.gmail.com>
Message-ID: <CAAP_wukbWxO8kd3wwP2wd3aHHoxT8r94MgLvWq-YMXtiBMWxuQ@mail.gmail.com>

Regarding Wayland, I'm thinking to merge the EGL work I did (which is
required for Wayland) with the PR #1789, comment/replace X11 specific calls
(which aren't much now) and give it a go. It might work (not fully
because there's no absolute desktop coordinates).

-- Thiago

Em dom., 11 de mai. de 2025 ?s 08:57, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> I enjoyed it. Thanks!
>
>
> Em dom., 11 de mai. de 2025 ?s 04:59, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> Just saw Kevin's JavaFX talk released on YT. Thanks Kevin!
>>
>> https://www.youtube.com/watch?v=FxHbXY34iFQ
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250511/e2a89eaa/attachment.htm>

From tsayao at openjdk.org  Sun May 11 12:26:01 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 11 May 2025 12:26:01 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <3GX2phXtO0jM1eYtPYoB20SmbOsx4UgDRPDe7_0OlPM=.5c2c9153-83b8-4ade-bf40-34314aa54ebd@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <3GX2phXtO0jM1eYtPYoB20SmbOsx4UgDRPDe7_0OlPM=.5c2c9153-83b8-4ade-bf40-34314aa54ebd@github.com>
Message-ID: <JiafOIOwCUU2ghi86b68cagfc9ISPghH81QSoNDEjbM=.059d6f3f-0795-454d-b38a-28a4e7cc2abd@github.com>

On Wed, 7 May 2025 13:40:13 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-debug build
>
> tests/system/src/test/java/test/robot/javafx/stage/StageLocationTest.java line 91:
> 
>> 89:                     stage.setY(Y);
>> 90:                 },
>> 91:                 stage::show,
> 
> On my Windows 11 machine this consistently fails for DECORATED stage, which is the very first test to be done from the collection. My guess is that this misses a `CountDownLatch` or some other way to ensure the Stage is fully shown.
> 
> I would also add a similar latch wait to other tests in this file. A common `showStage` method of sorts that calls `stage::show` and then waits for the latch seems to me like the best route. Plenty of other system tests use this pattern if you need to source the solution from somewhere.

Shown latches added.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2083510016

From tsayao at openjdk.org  Sun May 11 12:26:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 11 May 2025 12:26:02 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
Message-ID: <VCCKRQdyczBcRqKLw5qkpW4ou_dZ2LE6Aldx7ghL88Q=.9c481a6d-4106-43c7-98a6-4ab67b3eaff2@github.com>

On Wed, 7 May 2025 17:09:12 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-debug build
>
> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 343:
> 
>> 341:                 () -> {
>> 342:                     assertTrue(stage0.isIconified());
>> 343:                     assertTrue(stage1.isIconified());
> 
> When a window is iconified I would expect the OS to hide any owned windows but not iconify them. For example, the owned windows should not appear as thumbnails in the dock or task bar. If we want these to be reported as iconified we would have to update glass to do that.
> 
> My first impulse is to not change anything but currently JavaFX has no way of knowing that the owned windows have changed state and can't be drawn to. We can't report them as hidden because that means something else in JavaFX. Modifying glass to report them as iconified might actually be the right thing to do even though they're not actually iconified.

I removed the children iconified assertions and kept the color checks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2083509958

From tsayao at openjdk.org  Sun May 11 12:26:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 11 May 2025 12:26:02 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <-e3004pK5tFoHDR7S3hjMZPsMJT_eeBZbdqmJKM3kwM=.3f338f03-26d1-4f7e-ae63-73a3537127df@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
 <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>
 <LzCrUfxy8DGXhWWZFCe_4WCKBEL_ks1p7r-A6zV7zqk=.7223b29c-263d-4ccf-86a5-67195f90200c@github.com>
 <-e3004pK5tFoHDR7S3hjMZPsMJT_eeBZbdqmJKM3kwM=.3f338f03-26d1-4f7e-ae63-73a3537127df@github.com>
Message-ID: <6ucekCPrcMemDlS4jN3rM-JieyN92vEO0X_jXsi4NU8=.1b499a0f-0b02-4ebf-b5c6-2784a3c468f3@github.com>

On Wed, 7 May 2025 20:36:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> When stage2 is created you pass in stage0 as the owner, not stage1.
>
> Sorry, my bad, you're right. I now hide in shame..

Fixed it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2083509590

From tsayao at openjdk.org  Sun May 11 12:29:57 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 11 May 2025 12:29:57 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v20]
In-Reply-To: <oOIOa5HQa2uvhchi-eQ783hdE7qLp4PRaUq2BWWnNZI=.542897be-13f9-4112-8a0b-89d2d65505a3@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <oOIOa5HQa2uvhchi-eQ783hdE7qLp4PRaUq2BWWnNZI=.542897be-13f9-4112-8a0b-89d2d65505a3@github.com>
Message-ID: <ramzefHAxO1PYnLFOzocG08KyEvzDrYkrFivWeBXNrY=.01c5a4ed-1a08-42dc-9bbb-1edf27e5f050@github.com>

On Sun, 11 May 2025 12:14:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Review fixes
>   - Fix Focus
>   - Improvements on TestStage to assist testing

There are still two bugs I need to fix (that I know of):
- Popup menu grab is not working;
- Sometimes there's a glitch of the size of the decoration on top of the view;

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2869825149

From mstrauss at openjdk.org  Sun May 11 20:14:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 11 May 2025 20:14:50 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v74]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <SX6dr1hxwiSY6P07FjnhP7ms-_6vzsw7ioV_p2WrM3E=.64f700d8-20a1-45e8-8ab8-076ed7b5d752@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

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

  javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/e09adfe5..fe7b6c7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=73
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=72-73

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

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

From kevin.rushforth at oracle.com  Mon May 12 12:19:45 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 12 May 2025 05:19:45 -0700
Subject: JavaFX Presentation at JavaOne
In-Reply-To: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
References: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
Message-ID: <4f8f6cc5-e6a9-4c39-b2bb-13d24ce5ad0f@oracle.com>

Thanks for posting this.

-- Kevin

On 5/10/2025 10:32 PM, Nir Lisker wrote:
> Just saw Kevin's JavaFX talk released on YT. Thanks Kevin!
>
> https://www.youtube.com/watch?v=FxHbXY34iFQ


From kcr at openjdk.org  Mon May 12 13:26:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 May 2025 13:26:58 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <jTrgsvxEhaEebZCQyJCIx81TxdopUbcEySdDo_anhrw=.ab544aa5-274a-48c2-a159-7aeba3379017@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

I'll review this. I need to upload the new binaries to our build server and do a CI test run.

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

PR Comment: https://git.openjdk.org/jfx/pull/1803#issuecomment-2872565221

From angorya at openjdk.org  Mon May 12 14:52:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 May 2025 14:52:56 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
Message-ID: <Hsz3kHjDsyJ0g4mAycqwOjp6MZUWRkk16eykbVafpSQ=.7ca9e6dc-ae80-4510-9243-838813542424@github.com>

On Fri, 9 May 2025 10:51:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TreeCellSkin.java

excellent work, thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1715#pullrequestreview-2833533626

From zjx001202 at gmail.com  Mon May 12 15:44:45 2025
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 12 May 2025 23:44:45 +0800
Subject: Add more useful APIs to javafx.scene.text.Font
In-Reply-To: <CAJL5A3maeoaJmrbEd+54-RZ-B70Z3ZBrxnEodSzE6MW0iCWH=A@mail.gmail.com>
References: <CAJL5A3maeoaJmrbEd+54-RZ-B70Z3ZBrxnEodSzE6MW0iCWH=A@mail.gmail.com>
Message-ID: <CAJL5A3mZg6F8q7fy0CKWAcNtJ+gciCihiNSckjKLFMeeauy8JQ@mail.gmail.com>

I hope this issue gets more attention. Can anyone take a look at this email?

Glavo

On Sun, May 4, 2025 at 4:18?PM Glavo <zjx001202 at gmail.com> wrote:

> Hi,
>
> We have noticed that JavaFX's strategy for selecting default fonts can
> sometimes be quite odd,
> and at times it doesn't properly follow the fontconfig configuration. As a
> result,
> we frequently receive feedback from Linux users reporting that all Chinese
> characters appear as garbled text.
> This[1] is one piece of the feedback that contains useful information.
>
> We are not sure whether these problems can be solved. However, we've
> noticed that unlike AWT,
> javafx.scene.text.Font API lacks most useful methods. For example, it does
> not provide
> canDisplay/canDisplayUpTo methods, making it impossible to determine
> whether
> a font can render a given text. I found that CharToGlyphMapper actually
> contains
> the corresponding method, but it is not exposed through the Font API.
>
> So is it possible to add more useful API methods to Font, like AWT does?
> This will be of great help to us.
>
> Glavo
>
> [1]: https://github.com/HMCL-dev/HMCL/issues/3104
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250512/fc31c474/attachment.htm>

From angorya at openjdk.org  Mon May 12 16:22:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 May 2025 16:22:00 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread [v2]
In-Reply-To: <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
 <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
Message-ID: <rcb_cz18cVWECbvowaGDd0iQQbFt-kUNxhvHGDk6OB8=.5561e0a1-7fbd-4794-b706-5a4cc3258c0e@github.com>

On Fri, 2 May 2025 15:44:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
>> 
>> Also, ensure that the reverse process also happens in the FX application thread.
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8355615.menubar
>  - in fx thread
>  - install

@arapte could you please take a look at this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1795#issuecomment-2873202229

From andy.goryachev at oracle.com  Mon May 12 16:28:28 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 12 May 2025 16:28:28 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
Message-ID: <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>

Pavel:

Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).  On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 22:18
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!

Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
that the internet is extremely popular today and that links in code are common practice, and so on.

Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
when styling is completely separated from logic.

So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
core properties are supported.

That's just my feedback ? the decision is, of course, yours :)

Best regards, Pavel
On 5/9/25 00:09, Andy Goryachev wrote:
The only property that makes sense is the background color.  The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.  The highlights were designed specifically for the case to highlight the content range regardless of what is in it.

I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.

Thank you for your patience and good suggestions!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 13:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel
On 5/8/25 22:21, Andy Goryachev wrote:
Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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



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

From pavelturk2000 at gmail.com  Mon May 12 16:34:23 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 12 May 2025 19:34:23 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>

Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.

Best regards, Pavel

On 5/12/25 19:28, Andy Goryachev wrote:
>
> Pavel:
>
> Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).? On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 8, 2025 at 22:18
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!
>
> Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
> that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
> that the internet is extremely popular today and that links in code are common practice, and so on.
>
> Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
> when styling is completely separated from logic.
>
> So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
> core properties are supported.
>
> That's just my feedback ? the decision is, of course, yours :)
>
> Best regards, Pavel
>
> On 5/9/25 00:09, Andy Goryachev wrote:
>
>     The only property that makes sense is the background color.? The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.? The highlights were designed specifically for the case to highlight the content range regardless of what is in it.
>
>     I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.
>
>     Thank you for your patience and good suggestions!
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Thursday, May 8, 2025 at 13:13
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     Since we?re talking about code styling, I would highlight the following as the main properties:
>     - foreground color (+)
>     - background color (-)
>     - font (weight, italic, size, name) (+)
>     - underline (e.g. for links) (?)
>     - wavy underline (e.g. for spelling) (-)
>
>     I think these properties cover 99% of all the necessary properties for CodeArea.
>     I used + and - to show what has already been implemented.
>
>     Best regards, Pavel
>
>     On 5/8/25 22:21, Andy Goryachev wrote:
>
>         Oh, I finally get it what you want.? Thanks!
>
>         What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).? My first question is - what are the additional properties, beside the background-color?? If it's only the background color, it's probably easy to add.
>
>         Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Thursday, May 8, 2025 at 11:44
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>         Andy, thank you for your reply.
>
>         I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
>         I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
>         how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
>         CSS file, there is a class:
>
>         .search-match {
>         ??? -fx-background-color: orange;
>         }
>
>         But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
>         .search-match {
>         ??? -fx-fill: orange;
>         ??? -fx-font-weight: bold;
>         }
>
>         And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
>         If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
>         such as -fx-highlight-color. However, everything else in the example should work as described.
>
>         Best regards, Pavel
>
>         On 5/8/25 21:25, Andy Goryachev wrote:
>
>             Pavel:
>
>             I think your comments in the ticket are still invisible to me, so I can't comment.
>
>             About your recent comment in the PR - I have difficulty understanding what you mean. We are not adding methods to "style individual properties".? We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>             Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Thursday, May 8, 2025 at 11:04
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>             I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>             methods for styling individual properties is a very problematic and dangerous decision.
>
>             First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>             adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>             result wants to set background color for matches but another one wants to set foreground color + weight.
>             Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>             be removed without breaking backward compatibility.
>
>             I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>             by a moderator.
>
>             When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>             which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>             This is my personal opinion, which, of course, can be wrong.
>
>             Best regards, Pavel
>
>             On 5/8/25 20:46, Andy Goryachev wrote:
>             > 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) {
>             >
>             > -------------
>             >
>             > Commit messages:
>             >?? - tab
>             >?? - css
>             >
>             > Changes: https://git.openjdk.org/jfx/pull/1802/files
>             >??? Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>             >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>             >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250512/c5695c2d/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon May 12 16:41:41 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 12 May 2025 16:41:41 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
Message-ID: <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>

Yes, I know.  But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.  Our goal is to provide the tools that can be used equally well in either situation.  "The most frequent operations must be easy, all other must be possible".

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 09:34
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.

Best regards, Pavel

On 5/12/25 19:28, Andy Goryachev wrote:

Pavel:

Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).  On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 22:18
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!

Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
that the internet is extremely popular today and that links in code are common practice, and so on.

Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
when styling is completely separated from logic.

So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
core properties are supported.

That's just my feedback ? the decision is, of course, yours :)

Best regards, Pavel
On 5/9/25 00:09, Andy Goryachev wrote:
The only property that makes sense is the background color.  The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.  The highlights were designed specifically for the case to highlight the content range regardless of what is in it.

I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.

Thank you for your patience and good suggestions!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 13:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel
On 5/8/25 22:21, Andy Goryachev wrote:
Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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




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

From pavelturk2000 at gmail.com  Mon May 12 16:48:38 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 12 May 2025 19:48:38 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
 <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>

Thank you very much for the detailed explanation. Am I right in understanding that JDK-8355774 does not
consider the possibility of styling underline/wavy underline via a CSS file (without calling special methods
like addHighlight, addWavyUnderline?

If so, should I open another issue?

Best regards, Pavel

On 5/12/25 19:41, Andy Goryachev wrote:
>
> Yes, I know.? But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.? Our goal is to provide the tools that can be used equally well in either situation.? "The most frequent operations must be easy, all other must be possible".
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 12, 2025 at 09:34
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.
>
> Best regards, Pavel
>
> On 5/12/25 19:28, Andy Goryachev wrote:
>
>     Pavel:
>
>     Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color). On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Thursday, May 8, 2025 at 22:18
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!
>
>     Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
>     that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
>     that the internet is extremely popular today and that links in code are common practice, and so on.
>
>     Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
>     when styling is completely separated from logic.
>
>     So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
>     core properties are supported.
>
>     That's just my feedback ? the decision is, of course, yours :)
>
>     Best regards, Pavel
>
>     On 5/9/25 00:09, Andy Goryachev wrote:
>
>         The only property that makes sense is the background color.? The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images. The highlights were designed specifically for the case to highlight the content range regardless of what is in it.
>
>         I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.
>
>         Thank you for your patience and good suggestions!
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Thursday, May 8, 2025 at 13:13
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>         Since we?re talking about code styling, I would highlight the following as the main properties:
>         - foreground color (+)
>         - background color (-)
>         - font (weight, italic, size, name) (+)
>         - underline (e.g. for links) (?)
>         - wavy underline (e.g. for spelling) (-)
>
>         I think these properties cover 99% of all the necessary properties for CodeArea.
>         I used + and - to show what has already been implemented.
>
>         Best regards, Pavel
>
>         On 5/8/25 22:21, Andy Goryachev wrote:
>
>             Oh, I finally get it what you want.? Thanks!
>
>             What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).? My first question is - what are the additional properties, beside the background-color? If it's only the background color, it's probably easy to add.
>
>             Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Thursday, May 8, 2025 at 11:44
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>             Andy, thank you for your reply.
>
>             I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
>             I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
>             how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
>             CSS file, there is a class:
>
>             .search-match {
>             -fx-background-color: orange;
>             }
>
>             But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
>             .search-match {
>             ??? -fx-fill: orange;
>             ??? -fx-font-weight: bold;
>             }
>
>             And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
>             If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
>             such as -fx-highlight-color. However, everything else in the example should work as described.
>
>             Best regards, Pavel
>
>             On 5/8/25 21:25, Andy Goryachev wrote:
>
>                 Pavel:
>
>                 I think your comments in the ticket are still invisible to me, so I can't comment.
>
>                 About your recent comment in the PR - I have difficulty understanding what you mean.? We are not adding methods to "style individual properties".? We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>                 Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Thursday, May 8, 2025 at 11:04
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                 I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>                 methods for styling individual properties is a very problematic and dangerous decision.
>
>                 First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>                 adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>                 result wants to set background color for matches but another one wants to set foreground color + weight.
>                 Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>                 be removed without breaking backward compatibility.
>
>                 I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>                 by a moderator.
>
>                 When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>                 which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>                 This is my personal opinion, which, of course, can be wrong.
>
>                 Best regards, Pavel
>
>                 On 5/8/25 20:46, Andy Goryachev wrote:
>                 > 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) {
>                 >
>                 > -------------
>                 >
>                 > Commit messages:
>                 >?? - tab
>                 >?? - css
>                 >
>                 > Changes: https://git.openjdk.org/jfx/pull/1802/files
>                 > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>                 >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>                 >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250512/f7e98dac/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon May 12 16:58:41 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 12 May 2025 16:58:41 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
 <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>
Message-ID: <CY8PR10MB7265A12E68365EA3B4E61CF2E597A@CY8PR10MB7265.namprd10.prod.outlook.com>

JDK-8355774 adds methods to style highlights added via addHighlight() with CSS.

What (I think) you want is an ability to style a single text segment with (background | underlines | etc) attributes, which is still debatable - because you already can do all that, albeit with some additional code.  The addHighlight() is more flexible, as it allows to style not only the segment being added, but also multiple segments of parts of segments.  So, in effect, the existing APIs (plus JDK-8355774) allow you address your requirements.

Or is there something you that is still impossible to do?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 09:49
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Thank you very much for the detailed explanation. Am I right in understanding that JDK-8355774 does not
consider the possibility of styling underline/wavy underline via a CSS file (without calling special methods
like addHighlight, addWavyUnderline?

If so, should I open another issue?

Best regards, Pavel
On 5/12/25 19:41, Andy Goryachev wrote:
Yes, I know.  But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.  Our goal is to provide the tools that can be used equally well in either situation.  "The most frequent operations must be easy, all other must be possible".

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 09:34
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.

Best regards, Pavel

On 5/12/25 19:28, Andy Goryachev wrote:
Pavel:

Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).  On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 22:18
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!

Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
that the internet is extremely popular today and that links in code are common practice, and so on.

Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
when styling is completely separated from logic.

So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
core properties are supported.

That's just my feedback ? the decision is, of course, yours :)

Best regards, Pavel
On 5/9/25 00:09, Andy Goryachev wrote:
The only property that makes sense is the background color.  The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.  The highlights were designed specifically for the case to highlight the content range regardless of what is in it.

I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.

Thank you for your patience and good suggestions!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 13:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel
On 5/8/25 22:21, Andy Goryachev wrote:
Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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





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

From mfox at openjdk.org  Mon May 12 17:25:59 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 12 May 2025 17:25:59 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <tr4i7d-yveTeEoYML3x-B4_lzXqVxQtQzQflI_0Bd6A=.8e90d337-eb82-468e-864d-bf16d03ece6a@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

Test file attached. [drawdeiconify.patch](https://github.com/user-attachments/files/20165986/drawdeiconify.patch)

The test fails on all platforms without this PR. With this PR the test succeeds on Linux and Windows for regular windows and fails when de-iconifying to a maximized state. It also fails on Windows for TRANSPARENT stages since we never get a WM_PAINT message and so glass never calls notifyRepaint.

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

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2873374444

From pavelturk2000 at gmail.com  Mon May 12 17:31:05 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 12 May 2025 20:31:05 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <CY8PR10MB7265A12E68365EA3B4E61CF2E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
 <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>
 <CY8PR10MB7265A12E68365EA3B4E61CF2E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <36a6a377-d0a4-4370-91a4-f00b07e4c62f@gmail.com>

Andy, thank you for your time and the detailed discussion. I'm sure it was very helpful.

That's why I just opened a new issue with ID: 9078500.

Best regards, Pavel

On 5/12/25 19:58, Andy Goryachev wrote:
>
> JDK-8355774 adds methods to style highlights added via addHighlight() with CSS.
>
> What (I think) you want is an ability to style a single text segment with (background | underlines | etc) attributes, which is still debatable - because you already can do all that, albeit with some additional code.? The addHighlight() is more flexible, as it allows to style not only the segment being added, but also multiple segments of parts of segments.? So, in effect, the existing APIs (plus JDK-8355774) allow you address your requirements.
>
> Or is there something you that is still impossible to do?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 12, 2025 at 09:49
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Thank you very much for the detailed explanation. Am I right in understanding that JDK-8355774 does not
> consider the possibility of styling underline/wavy underline via a CSS file (without calling special methods
> like addHighlight, addWavyUnderline?
>
> If so, should I open another issue?
>
> Best regards, Pavel
>
> On 5/12/25 19:41, Andy Goryachev wrote:
>
>     Yes, I know.? But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.? Our goal is to provide the tools that can be used equally well in either situation. "The most frequent operations must be easy, all other must be possible".
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 12, 2025 at 09:34
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.
>
>     Best regards, Pavel
>
>     On 5/12/25 19:28, Andy Goryachev wrote:
>
>         Pavel:
>
>         Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).? On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Thursday, May 8, 2025 at 22:18
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>         Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!
>
>         Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
>         that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
>         that the internet is extremely popular today and that links in code are common practice, and so on.
>
>         Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
>         when styling is completely separated from logic.
>
>         So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
>         core properties are supported.
>
>         That's just my feedback ? the decision is, of course, yours :)
>
>         Best regards, Pavel
>
>         On 5/9/25 00:09, Andy Goryachev wrote:
>
>             The only property that makes sense is the background color.? The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images. The highlights were designed specifically for the case to highlight the content range regardless of what is in it.
>
>             I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.
>
>             Thank you for your patience and good suggestions!
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Thursday, May 8, 2025 at 13:13
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>             Since we?re talking about code styling, I would highlight the following as the main properties:
>             - foreground color (+)
>             - background color (-)
>             - font (weight, italic, size, name) (+)
>             - underline (e.g. for links) (?)
>             - wavy underline (e.g. for spelling) (-)
>
>             I think these properties cover 99% of all the necessary properties for CodeArea.
>             I used + and - to show what has already been implemented.
>
>             Best regards, Pavel
>
>             On 5/8/25 22:21, Andy Goryachev wrote:
>
>                 Oh, I finally get it what you want. Thanks!
>
>                 What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text). My first question is - what are the additional properties, beside the background-color? If it's only the background color, it's probably easy to add.
>
>                 Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Thursday, May 8, 2025 at 11:44
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                 Andy, thank you for your reply.
>
>                 I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
>                 I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
>                 how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
>                 CSS file, there is a class:
>
>                 .search-match {
>                 -fx-background-color: orange;
>                 }
>
>                 But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
>                 .search-match {
>                 ??? -fx-fill: orange;
>                 -fx-font-weight: bold;
>                 }
>
>                 And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
>                 If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
>                 such as -fx-highlight-color. However, everything else in the example should work as described.
>
>                 Best regards, Pavel
>
>                 On 5/8/25 21:25, Andy Goryachev wrote:
>
>                     Pavel:
>
>                     I think your comments in the ticket are still invisible to me, so I can't comment.
>
>                     About your recent comment in the PR - I have difficulty understanding what you mean.? We are not adding methods to "style individual properties". We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>                     Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>                     -andy
>
>                     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                     *Date: *Thursday, May 8, 2025 at 11:04
>                     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                     I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>                     methods for styling individual properties is a very problematic and dangerous decision.
>
>                     First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>                     adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>                     result wants to set background color for matches but another one wants to set foreground color + weight.
>                     Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>                     be removed without breaking backward compatibility.
>
>                     I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>                     by a moderator.
>
>                     When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>                     which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>                     This is my personal opinion, which, of course, can be wrong.
>
>                     Best regards, Pavel
>
>                     On 5/8/25 20:46, Andy Goryachev wrote:
>                     > 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) {
>                     >
>                     > -------------
>                     >
>                     > Commit messages:
>                     >?? - tab
>                     >?? - css
>                     >
>                     > Changes: https://git.openjdk.org/jfx/pull/1802/files
>                     > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>                     >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>                     >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250512/d6935aff/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon May 12 17:40:10 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 12 May 2025 17:40:10 +0000
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <36a6a377-d0a4-4370-91a4-f00b07e4c62f@gmail.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <42c5cf98-2a26-4f6a-a95b-d4572e113518@gmail.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
 <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>
 <CY8PR10MB7265A12E68365EA3B4E61CF2E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <36a6a377-d0a4-4370-91a4-f00b07e4c62f@gmail.com>
Message-ID: <CY8PR10MB7265FD69F4966C211D47C995E597A@CY8PR10MB7265.namprd10.prod.outlook.com>

Pavel:

if you don't mind, could you forward the text from the bug to the mailing list as a new message, so it does not get appended to the PR?
The reason is - it'll take some time to percolate the ticket through the webbugs system.

Thanks!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 10:31
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your time and the detailed discussion. I'm sure it was very helpful.

That's why I just opened a new issue with ID: 9078500.

Best regards, Pavel
On 5/12/25 19:58, Andy Goryachev wrote:
JDK-8355774 adds methods to style highlights added via addHighlight() with CSS.

What (I think) you want is an ability to style a single text segment with (background | underlines | etc) attributes, which is still debatable - because you already can do all that, albeit with some additional code.  The addHighlight() is more flexible, as it allows to style not only the segment being added, but also multiple segments of parts of segments.  So, in effect, the existing APIs (plus JDK-8355774) allow you address your requirements.

Or is there something you that is still impossible to do?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 09:49
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Thank you very much for the detailed explanation. Am I right in understanding that JDK-8355774 does not
consider the possibility of styling underline/wavy underline via a CSS file (without calling special methods
like addHighlight, addWavyUnderline?

If so, should I open another issue?

Best regards, Pavel
On 5/12/25 19:41, Andy Goryachev wrote:
Yes, I know.  But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.  Our goal is to provide the tools that can be used equally well in either situation.  "The most frequent operations must be easy, all other must be possible".

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 12, 2025 at 09:34
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.

Best regards, Pavel

On 5/12/25 19:28, Andy Goryachev wrote:
Pavel:

Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).  On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 22:18
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!

Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
that the internet is extremely popular today and that links in code are common practice, and so on.

Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
when styling is completely separated from logic.

So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
core properties are supported.

That's just my feedback ? the decision is, of course, yours :)

Best regards, Pavel
On 5/9/25 00:09, Andy Goryachev wrote:
The only property that makes sense is the background color.  The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.  The highlights were designed specifically for the case to highlight the content range regardless of what is in it.

I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.

Thank you for your patience and good suggestions!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 13:13
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Since we?re talking about code styling, I would highlight the following as the main properties:
- foreground color (+)
- background color (-)
- font (weight, italic, size, name) (+)
- underline (e.g. for links) (?)
- wavy underline (e.g. for spelling) (-)

I think these properties cover 99% of all the necessary properties for CodeArea.
I used + and - to show what has already been implemented.

Best regards, Pavel
On 5/8/25 22:21, Andy Goryachev wrote:
Oh, I finally get it what you want.  Thanks!

What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).  My first question is - what are the additional properties, beside the background-color?  If it's only the background color, it's probably easy to add.

Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:44
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
Andy, thank you for your reply.

I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.

I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
CSS file, there is a class:

.search-match {
    -fx-background-color: orange;
}

But the user wants to change not the background color, but the foreground color and font weight. So they write:

.search-match {
    -fx-fill: orange;
    -fx-font-weight: bold;
}

And this should work. If it doesn?t, then it?s no longer CSS-based styling.

If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
such as -fx-highlight-color. However, everything else in the example should work as described.

Best regards, Pavel
On 5/8/25 21:25, Andy Goryachev wrote:
Pavel:

I think your comments in the ticket are still invisible to me, so I can't comment.

About your recent comment in the PR - I have difficulty understanding what you mean.  We are not adding methods to "style individual properties".  We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.

Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Thursday, May 8, 2025 at 11:04
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
methods for styling individual properties is a very problematic and dangerous decision.

First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
result wants to set background color for matches but another one wants to set foreground color + weight.
Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
be removed without breaking backward compatibility.

I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
by a moderator.

When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.

This is my personal opinion, which, of course, can be wrong.

Best regards, Pavel

On 5/8/25 20:46, Andy Goryachev wrote:
> 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) {
>
> -------------
>
> Commit messages:
>   - tab
>   - css
>
> Changes: https://git.openjdk.org/jfx/pull/1802/files
>    Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8355774
>    Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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






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

From pavelturk2000 at gmail.com  Mon May 12 17:45:00 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 12 May 2025 20:45:00 +0300
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights
In-Reply-To: <CY8PR10MB7265FD69F4966C211D47C995E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <BYAPR10MB3013BDC6A4D8DA7106D51B45E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <95e4c3ab-6e04-4a1b-bd3f-010e8458972f@gmail.com>
 <BYAPR10MB3013CE9068415AD930E9825FE58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <587ac65c-d147-485d-9a7d-88095fb77ba3@gmail.com>
 <BYAPR10MB3013A2D686AB8E5A7C4CB0B1E58BA@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6492b005-9876-49f7-bf0b-5db8dde58a5a@gmail.com>
 <CY8PR10MB7265DCAC119F02D3CFD8331EE597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <3ebf6206-2a9f-424d-aebf-10038598e915@gmail.com>
 <CY8PR10MB726596480AB75E947DF08A01E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <b8b1c6ef-c2e8-43c5-881c-00889a842d81@gmail.com>
 <CY8PR10MB7265A12E68365EA3B4E61CF2E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <36a6a377-d0a4-4370-91a4-f00b07e4c62f@gmail.com>
 <CY8PR10MB7265FD69F4966C211D47C995E597A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <c1c8b43e-0c25-4eeb-a588-a70cfca0ce7c@gmail.com>

Andy, unfortunately, I don't have that text and the link to the issue will come only when the issue is approved.
Sorry, we can only wait now.

Best regards. Pavel

On 5/12/25 20:40, Andy Goryachev wrote:
>
> Pavel:
>
> if you don't mind, could you forward the text from the bug to the mailing list as a new message, so it does not get appended to the PR?
>
> The reason is - it'll take some time to percolate the ticket through the webbugs system.
>
> Thanks!
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 12, 2025 at 10:31
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
> Andy, thank you for your time and the detailed discussion. I'm sure it was very helpful.
>
> That's why I just opened a new issue with ID: 9078500.
>
> Best regards, Pavel
>
> On 5/12/25 19:58, Andy Goryachev wrote:
>
>     JDK-8355774 adds methods to style highlights added via addHighlight() with CSS.
>
>     What (I think) you want is an ability to style a single text segment with (background | underlines | etc) attributes, which is still debatable - because you already can do all that, albeit with some additional code.? The addHighlight() is more flexible, as it allows to style not only the segment being added, but also multiple segments of parts of segments.? So, in effect, the existing APIs (plus JDK-8355774) allow you address your requirements.
>
>     Or is there something you that is still impossible to do?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, May 12, 2025 at 09:49
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>     Thank you very much for the detailed explanation. Am I right in understanding that JDK-8355774 does not
>     consider the possibility of styling underline/wavy underline via a CSS file (without calling special methods
>     like addHighlight, addWavyUnderline?
>
>     If so, should I open another issue?
>
>     Best regards, Pavel
>
>     On 5/12/25 19:41, Andy Goryachev wrote:
>
>         Yes, I know.? But we must support both options, since the RichTextArea provides models that allow to style programmatically and independently from the stylesheet.? Our goal is to provide the tools that can be used equally well in either situation.? "The most frequent operations must be easy, all other must be possible".
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>         *Date: *Monday, May 12, 2025 at 09:34
>         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>         Andy, thank you very much for your response. But as I?ve said many times, I?m only considering styling through a CSS file.
>
>         Best regards, Pavel
>
>         On 5/12/25 19:28, Andy Goryachev wrote:
>
>             Pavel:
>
>             Underlines and strike-through attributes are available via StyleAttributeMap.STRIKE_THROUGH and StyleAttributeMap.UNDERLINE (using text color).? On the other hand, adding this functionality via addHighlight() would allow the application to style the shapes via CSS.
>
>             -andy
>
>             *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>             *Date: *Thursday, May 8, 2025 at 22:18
>             *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>             *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>             Andy, I'm really glad we figured out the background-color issue, and I'm also very grateful to you!
>
>             Regarding wavy lines and other types of underlining ? in my previous message, I listed the key attributes
>             that are essential for a modern CodeArea. For example, underline for links ? I don't think it's necessary to write
>             that the internet is extremely popular today and that links in code are common practice, and so on.
>
>             Of course, all of these properties should be set via a CSS file, since that's the most efficient way to use CSS ?
>             when styling is completely separated from logic.
>
>             So, the list contains five properties. If two of them are not supported, that means (to me) that only 60% of the
>             core properties are supported.
>
>             That's just my feedback ? the decision is, of course, yours :)
>
>             Best regards, Pavel
>
>             On 5/9/25 00:09, Andy Goryachev wrote:
>
>                 The only property that makes sense is the background color. The wavy and other kinds of underlines, while they make some sense in the context of the CodeArea, would fail in general in the context of RichTextArea where the content may include nodes and images.? The highlights were designed specifically for the case to highlight the content range regardless of what is in it.
>
>                 I've reopened https://bugs.openjdk.org/browse/JDK-8356436 for the background color.
>
>                 Thank you for your patience and good suggestions!
>
>                 -andy
>
>                 *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                 *Date: *Thursday, May 8, 2025 at 13:13
>                 *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                 *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                 Since we?re talking about code styling, I would highlight the following as the main properties:
>                 - foreground color (+)
>                 - background color (-)
>                 - font (weight, italic, size, name) (+)
>                 - underline (e.g. for links) (?)
>                 - wavy underline (e.g. for spelling) (-)
>
>                 I think these properties cover 99% of all the necessary properties for CodeArea.
>                 I used + and - to show what has already been implemented.
>
>                 Best regards, Pavel
>
>                 On 5/8/25 22:21, Andy Goryachev wrote:
>
>                     Oh, I finally get it what you want.? Thanks!
>
>                     What you asking is effectively to add support for some additional properties to the class that renders the text segment (currently, Text).? My first question is - what are the additional properties, beside the background-color? If it's only the background color, it's probably easy to add.
>
>                     Anything beyond that, such as equivalent of full -fx-region-background or -fx-region-border, would be extremely unlikely.
>
>                     -andy
>
>                     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                     *Date: *Thursday, May 8, 2025 at 11:44
>                     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                     *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                     Andy, thank you for your reply.
>
>                     I have already provided some examples, but I?ll give one more very simple example that clearly illustrates the problem.
>
>                     I have a library that uses JFX CodeArea. Naturally, all styles are stored in a CSS file. Users of this library can customize
>                     how the code is displayed by modifying the styles in the CSS file. Let?s take the search feature as an example. In the
>                     CSS file, there is a class:
>
>                     .search-match {
>                     -fx-background-color: orange;
>                     }
>
>                     But the user wants to change not the background color, but the foreground color and font weight. So they write:
>
>                     .search-match {
>                     ??? -fx-fill: orange;
>                     -fx-font-weight: bold;
>                     }
>
>                     And this should work. If it doesn?t, then it?s no longer CSS-based styling.
>
>                     If, for some reason, the -fx-background-color property cannot be used, an alternative property can be introduced,
>                     such as -fx-highlight-color. However, everything else in the example should work as described.
>
>                     Best regards, Pavel
>
>                     On 5/8/25 21:25, Andy Goryachev wrote:
>
>                         Pavel:
>
>                         I think your comments in the ticket are still invisible to me, so I can't comment.
>
>                         About your recent comment in the PR - I have difficulty understanding what you mean.? We are not adding methods to "style individual properties". We are adding methods that allow the application to use CSS to style parts of the visual representation of the given RichParagraph.
>
>                         Perhaps if you describe what kind of visual representation you have in mind, we can show how to achieve that in the code.
>
>                         -andy
>
>                         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>                         *Date: *Thursday, May 8, 2025 at 11:04
>                         *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>                         *Subject: *Re: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of highlights
>
>                         I am not a member of the JavaFX team, but if I may, I?d like to express my opinion. I believe that creating separate
>                         methods for styling individual properties is a very problematic and dangerous decision.
>
>                         First, the usefulness of such methods is minimal because when styling is done via CSS, the assumption is that
>                         adjusting the CSS file should be sufficient?something that won?t work in this case. For example one user for search
>                         result wants to set background color for matches but another one wants to set foreground color + weight.
>                         Second, it violates fundamental CSS principles. Third, if these methods are added to the API, they cannot later
>                         be removed without breaking backward compatibility.
>
>                         I wrote about this in detail in the additional information for JDK-8356436, but my comment has not yet been approved
>                         by a moderator.
>
>                         When in doubt, it?s very helpful to see how others are doing it. In RichTextFX, special CSS properties were introduced,
>                         which resulted in a consistent standard for applying CSS styles to all properties?fully aligned with established CSS norms.
>
>                         This is my personal opinion, which, of course, can be wrong.
>
>                         Best regards, Pavel
>
>                         On 5/8/25 20:46, Andy Goryachev wrote:
>                         > 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) {
>                         >
>                         > -------------
>                         >
>                         > Commit messages:
>                         >?? - tab
>                         >?? - css
>                         >
>                         > Changes: https://git.openjdk.org/jfx/pull/1802/files
>                         > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00 <https://webrevs.openjdk.org/?repo=jfx&pr=1802&range=00>
>                         >??? Issue: https://bugs.openjdk.org/browse/JDK-8355774
>                         >??? Stats: 128 lines in 4 files changed: 110 ins; 8 del; 10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250512/02541592/attachment-0001.htm>

From zelmidaoui at openjdk.org  Mon May 12 18:03:02 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 12 May 2025 18:03:02 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
Message-ID: <_W1pW8jR_8KLtwijJmxxMBqkDBb1MXHV8il6VjtGEcE=.cf124264-9129-429d-8b00-06549c8ec2b8@github.com>

On Fri, 9 May 2025 10:51:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TreeCellSkin.java

@arapte could you please take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1715#issuecomment-2873487432

From duke at openjdk.org  Mon May 12 20:28:58 2025
From: duke at openjdk.org (duke)
Date: Mon, 12 May 2025 20:28:58 GMT
Subject: Withdrawn: 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: <KWjSHjeXVIH1fPIM5jCO8H8wNmcMu3p75C_53syooQ4=.c90f917e-68d7-49b6-b62e-9d08711f96bc@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 pull request has been closed without being integrated.

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

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

From lkostyra at openjdk.org  Tue May 13 09:13:28 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 13 May 2025 09:13:28 GMT
Subject: RFR: 8351357: Resolve system test focus issues
Message-ID: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@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 (among tests mentioned in the first paragraph) and succeeds when `--no-daemon` flag is used.

I figured the test could be added to the repository and serve as a helper if someone else encounters similar problems.

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

Commit messages:
 - Add StageFocusTest

Changes: https://git.openjdk.org/jfx/pull/1804/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351357
  Stats: 116 lines in 1 file changed: 116 ins; 0 del; 0 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 arapte at openjdk.org  Tue May 13 12:32:02 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 13 May 2025 12:32:02 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
Message-ID: <E_K9AZ4xIy_9Sb6DhL-IwUr81KDelttk-UdAaeM0dns=.b5309a2a-a7e6-424a-85ed-ddfad78e9322@github.com>

On Wed, 7 May 2025 15:42:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Added newlines where they were missing;
>   - Removed ebug output;
>   - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1796#pullrequestreview-2836570196

From zelmidaoui at openjdk.org  Tue May 13 12:46:35 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 13 May 2025 12:46:35 GMT
Subject: RFR: 8089080: [TextArea] Caret disappear after pressing backspace to
 clear the content
Message-ID: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>

Fixed Caret disappear after unfocus then focus on the TextArea, the issue was happening because the caret position was set to -1 when we focus on the TextArea with empty text and caused the caret to disappear from at the skin level when the position is set to -1

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

Commit messages:
 - Merge branch 'openjdk:master' into 8089080.CaretTextArea
 - Merge branch 'openjdk:master' into 8089080.CaretTextArea
 - Fixed Caret disappear after focus and unfocus

Changes: https://git.openjdk.org/jfx/pull/1787/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8089080
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1787.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1787/head:pull/1787

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

From kizune at openjdk.org  Tue May 13 12:46:35 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 13 May 2025 12:46:35 GMT
Subject: RFR: 8089080: [TextArea] Caret disappear after pressing backspace
 to clear the content
In-Reply-To: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
References: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
Message-ID: <wRidujQBOsAGBerStcwft0LFGzjcvBcYy6fB6Yjb3iA=.8b0736e6-f8ab-4456-855f-ed1780e078f2@github.com>

On Mon, 21 Apr 2025 15:42:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed Caret disappear after unfocus then focus on the TextArea, the issue was happening because the caret position was set to -1 when we focus on the TextArea with empty text and caused the caret to disappear from at the skin level when the position is set to -1

Looks good.

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

Marked as reviewed by kizune (Author).

PR Review: https://git.openjdk.org/jfx/pull/1787#pullrequestreview-2834012171

From andy.goryachev at oracle.com  Tue May 13 14:51:06 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 13 May 2025 14:51:06 +0000
Subject: JavaFX Presentation at JavaOne
In-Reply-To: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
References: <CA+0ynh_zb0-Fs2qWeuUaDTMGX7XkC8PKAzS+7Zccbw-EqjVStQ@mail.gmail.com>
Message-ID: <CY8PR10MB72658BDB4786B35B4D8C11D2E596A@CY8PR10MB7265.namprd10.prod.outlook.com>

And a thread on reddit: https://www.reddit.com/r/java/s/IcJhCpNt7y
(Warning: S/N ratio)

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Date: Saturday, May 10, 2025 at 22:33
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: JavaFX Presentation at JavaOne
Just saw Kevin's JavaFX talk released on YT. Thanks Kevin!

https://www.youtube.com/watch?v=FxHbXY34iFQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250513/2781ee3e/attachment-0001.htm>

From angorya at openjdk.org  Tue May 13 15:25:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 May 2025 15:25:58 GMT
Subject: RFR: 8089080: [TextArea] Caret disappear after pressing backspace
 to clear the content
In-Reply-To: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
References: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
Message-ID: <as_AR_rQC2fanwO-8GfGEY6RQ-8HwL-RSituHnuFwSY=.5cc253ae-f04a-415a-a92a-3ba41af0044d@github.com>

On Mon, 21 Apr 2025 15:42:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed Caret disappear after unfocus then focus on the TextArea, the issue was happening because the caret position was set to -1 when we focus on the TextArea with empty text and caused the caret to disappear from at the skin level when the position is set to -1

Looks good!

Do you think it is possible to write a test for this case that would fail without the fix and pass with the fix?

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

PR Comment: https://git.openjdk.org/jfx/pull/1787#issuecomment-2876961470

From philip.race at oracle.com  Tue May 13 16:12:54 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 13 May 2025 09:12:54 -0700
Subject: Add more useful APIs to javafx.scene.text.Font
In-Reply-To: <CAJL5A3mZg6F8q7fy0CKWAcNtJ+gciCihiNSckjKLFMeeauy8JQ@mail.gmail.com>
References: <CAJL5A3maeoaJmrbEd+54-RZ-B70Z3ZBrxnEodSzE6MW0iCWH=A@mail.gmail.com>
 <CAJL5A3mZg6F8q7fy0CKWAcNtJ+gciCihiNSckjKLFMeeauy8JQ@mail.gmail.com>
Message-ID: <17225468-9615-4e92-be61-e71af9d5600e@oracle.com>


For the fonts like sans serif, FX just asks fontconfig for the list of 
fonts that make it up for the current locale.
Garbled text isn't likely to be due to a font selection difference. More 
likely a bug in mapping to the correct font
so I am not sure API methods on Font will help.

Also canDisplay() is a tricky one as I've discussed this recently on the 
client-libs list.
It was designed to report what glyphs *that physical font* supports.
Reporting pseudo-glyphs, and glyphs from fall backs distort it.

-phil.

On 5/12/25 8:44 AM, Glavo wrote:
> I hope this issue gets more attention.?Can anyone take a look at this 
> email?
>
> Glavo
>
> On Sun, May 4, 2025 at 4:18?PM Glavo <zjx001202 at gmail.com> wrote:
>
>     Hi,
>
>     We have noticed that JavaFX's strategy for selecting default fonts
>     can sometimes be quite odd,
>     and at times it doesn't properly follow the fontconfig
>     configuration. As a result,
>     we frequently receive feedback from Linux users reporting that all
>     Chinese characters appear as garbled text.
>     This[1] is one piece of the feedback that contains useful information.
>
>     We are not sure whether these problems can be solved. However,
>     we've noticed that unlike AWT,
>     javafx.scene.text.Font API lacks most useful methods. For example,
>     it does not provide
>     canDisplay/canDisplayUpTo methods, making it impossible to
>     determine whether
>     a font can render a given text. I found that CharToGlyphMapper
>     actually contains
>     the corresponding method, but it is not exposed through the Font API.
>
>     So is it possible to add more useful API methods to Font, like AWT
>     does?
>     This will be of great help to us.
>
>     Glavo
>
>     [1]: https://github.com/HMCL-dev/HMCL/issues/3104
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250513/75e5cfb2/attachment.htm>

From zelmidaoui at openjdk.org  Tue May 13 18:43:54 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 13 May 2025 18:43:54 GMT
Subject: RFR: 8089080: [TextArea] Caret disappear after pressing backspace
 to clear the content
In-Reply-To: <as_AR_rQC2fanwO-8GfGEY6RQ-8HwL-RSituHnuFwSY=.5cc253ae-f04a-415a-a92a-3ba41af0044d@github.com>
References: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
 <as_AR_rQC2fanwO-8GfGEY6RQ-8HwL-RSituHnuFwSY=.5cc253ae-f04a-415a-a92a-3ba41af0044d@github.com>
Message-ID: <LSP8E0EvgwBU2Wdflnueo6D103s2sniRBy6mZbBx4S4=.cb27657e-a66f-46b2-809c-ed6c345028f3@github.com>

On Tue, 13 May 2025 15:23:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Do you think it is possible to write a test for this case that would fail without the fix and pass with the fix?

I have tried to make a test for it but I cannot get the information about whether the caret is visible or the caret position as the expected I have tried the available methods like `isCaretVisible` and `getCaretPosition`, so not sure if that is possible.
Also for me the issue is not reproducible in the test case from the ticket but in Monkey tester by default the issue happens when focusing on the `TextArea` , with the fix the issue do not happen anymore.

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

PR Comment: https://git.openjdk.org/jfx/pull/1787#issuecomment-2877589924

From angorya at openjdk.org  Tue May 13 18:46:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 May 2025 18:46:56 GMT
Subject: RFR: 8089080: [TextArea] Caret disappear after pressing backspace
 to clear the content
In-Reply-To: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
References: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
Message-ID: <0gAuiVjgGQm2Cwat-TQElhZkyZ1gtwxrYh9JU8Gf9ig=.e75fcef8-b1f0-4167-b9a8-790084cf5684@github.com>

On Mon, 21 Apr 2025 15:42:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed Caret disappear after unfocus then focus on the TextArea, the issue was happening because the caret position was set to -1 when we focus on the TextArea with empty text and caused the caret to disappear from at the skin level when the position is set to -1

I see.  You are right - the fix is trivial enough, but the test is not.  I verified that failure is fixed in the monkey tester on macOS 15.4.1

Please wait the customary 24 hrs before integrating in case anyone else has  additional feedback.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1787#pullrequestreview-2837786526

From duke at openjdk.org  Wed May 14 05:06:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 14 May 2025 05:06:58 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol [v2]
In-Reply-To: <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <H2Q5q7PWX9PkXOWNJ7bAwHUtLsqcOhlbzntiYFNO-c4=.c125d9a6-b48b-4d86-898a-8f73c32ddea6@github.com>
Message-ID: <RL6l3KGtkKNZoBC5ZMCsT_ZyF3BqBUkhWWdL_XEp6z0=.69298078-8a88-47bb-99e7-59ead1c0413e@github.com>

On Wed, 7 May 2025 15:42:03 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Added newlines where they were missing;
>   - Removed ebug output;
>   - Added comment mentioning that JFXProgressIndicatorAccessibility serves both ProgressBar and ProgressIndicator controls.

@azuev-java 
Your change (at version 94bf9a1af027090a0246b10c260fe0d82ae55ed7) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2878686715

From gpattnaik at openjdk.org  Wed May 14 11:48:03 2025
From: gpattnaik at openjdk.org (Gopal Pattnaik)
Date: Wed, 14 May 2025 11:48:03 GMT
Subject: Withdrawn: 8260020: WebView does not render contents of locally stored
 MarkDown (*.md) files
In-Reply-To: <61xe7GY1wwduIUW9ilgSwa9QtF6OfT825eYHYLPeSo4=.a4b432f7-97c5-4a52-ad61-72fe7770fbdc@github.com>
References: <61xe7GY1wwduIUW9ilgSwa9QtF6OfT825eYHYLPeSo4=.a4b432f7-97c5-4a52-ad61-72fe7770fbdc@github.com>
Message-ID: <PkKXe86TYg4s7GCTbriCRE7tofvH-4RHbzW-PK4uno8=.0d2b5b70-e079-4b3b-80ce-797822bc5c47@github.com>

On Tue, 22 Apr 2025 06:54:31 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> Local markdown file mime type support is missing in the current JavaFX implementation. Hence, I have added a mime type for local Markdown files.
> 
> Verification:
> The test program attached to the JBS passes with this change.

This pull request has been closed without being integrated.

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

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

From kizune at openjdk.org  Wed May 14 12:31:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 14 May 2025 12:31:00 GMT
Subject: Integrated: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <p6p-c_OopALB_rJZhHn-y4i-Io5rbjX4JbqYP5JuKzw=.abc7f360-d580-4382-8166-a48259b35738@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

This pull request has now been integrated.

Changeset: c777efd7
Author:    Alexander Zuev <kizune at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c777efd7875d31ae47430e6e08e6420eeab39b0c
Stats:     194 lines in 5 files changed: 193 ins; 0 del; 1 mod

8350316: Create implementation of NSAccessibilityProgressIndicator protocol
8351773: Create implementation of NSAccessibilityGroup protocol

Reviewed-by: arapte, angorya

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

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

From arapte at openjdk.org  Wed May 14 14:05:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 14 May 2025 14:05:00 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
Message-ID: <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>

On Fri, 9 May 2025 10:51:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TreeCellSkin.java

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 232:

> 230:                                 cell.layout();
> 231:                             }
> 232:                         }

This would perform a layout of all cells, re-layout of previous cells and layout of next cells.
but, layout of next cells is performed again as continuation layout of TreeView.
A solution would be to break the loop when `cell` is current cell being layouted, so that at least the layout of next cells is not performed twice.

Can there be a way to avoid re-layout of previous cells, too ? ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089032872

From zelmidaoui at openjdk.org  Wed May 14 14:29:58 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 14 May 2025 14:29:58 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread [v2]
In-Reply-To: <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
 <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
Message-ID: <G26_LyVuX5MtR3D8m3OOmOYVdZ79SL468kEfzj0pDP4=.fa5295bc-0568-4749-9139-0878bd925d18@github.com>

On Fri, 2 May 2025 15:44:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
>> 
>> Also, ensure that the reverse process also happens in the FX application thread.
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8355615.menubar
>  - in fx thread
>  - install

LGTM.
I also confirmed that the test doesn't fail on my system without the fix. That said, the fix looks good and addresses the issue.

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

Marked as reviewed by zelmidaoui (Author).

PR Review: https://git.openjdk.org/jfx/pull/1795#pullrequestreview-2840438233

From arapte at openjdk.org  Wed May 14 14:31:03 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 14 May 2025 14:31:03 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
Message-ID: <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>

On Wed, 14 May 2025 14:02:06 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TreeCellSkin.java
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 232:
> 
>> 230:                                 cell.layout();
>> 231:                             }
>> 232:                         }
> 
> This would perform a layout of all cells, re-layout of previous cells and layout of next cells.
> but, layout of next cells is performed again as continuation layout of TreeView.
> A solution would be to break the loop when `cell` is current cell being layouted, so that at least the layout of next cells is not performed twice.
> 
> Can there be a way to avoid re-layout of previous cells, too ? ?

Also noticed a scenario: When a TreeCell with disclosureNode is currently not shown on screen but becomes visible on scrolling. In that case the TreeCells are layout while the scroll is in progress. I see only one way to avoid this that maxDisclosureWidthMap should reflect the correct value before starting the layout.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089090790

From angorya at openjdk.org  Wed May 14 14:36:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 May 2025 14:36:59 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread [v2]
In-Reply-To: <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
 <4H3QLtKzVUwjl78YqBY2ZN_S1s8Om7gPiDn-GFV6eOI=.cee69002-8dac-4252-811b-0a552d2e4c7c@github.com>
Message-ID: <0_Or33LB0Njvj0pgdD7mu9UQaa8Ntt-BrEKzmFjf7Bk=.13254c28-9d3a-4d56-acdf-a7dd999e0254@github.com>

On Fri, 2 May 2025 15:44:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
>> 
>> Also, ensure that the reverse process also happens in the FX application thread.
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8355615.menubar
>  - in fx thread
>  - install

Thank you all for reviewing this PR!

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

PR Comment: https://git.openjdk.org/jfx/pull/1795#issuecomment-2880484102

From angorya at openjdk.org  Wed May 14 14:37:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 May 2025 14:37:00 GMT
Subject: Integrated: 8355615: ConcurrentModificationException creating MenuBar
 on background thread
In-Reply-To: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
References: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>
Message-ID: <DsvG8cz0XqsyjqJ4foTCHNfkCjuTVbbk370CbbXEulo=.dbc32085-3e8c-46ff-9fcd-119ebcfe25a7@github.com>

On Fri, 25 Apr 2025 22:39:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.
> 
> Also, ensure that the reverse process also happens in the FX application thread.

This pull request has now been integrated.

Changeset: 4f60bc8c
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4f60bc8c429693f4431794415a4c84fa114411f8
Stats:     15 lines in 2 files changed: 11 ins; 0 del; 4 mod

8355615: ConcurrentModificationException creating MenuBar on background thread

Reviewed-by: kcr, zelmidaoui

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

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

From zelmidaoui at openjdk.org  Wed May 14 14:45:58 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 14 May 2025 14:45:58 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
Message-ID: <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>

On Wed, 14 May 2025 14:28:23 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 232:
>> 
>>> 230:                                 cell.layout();
>>> 231:                             }
>>> 232:                         }
>> 
>> This would perform a layout of all cells, re-layout of previous cells and layout of next cells.
>> but, layout of next cells is performed again as continuation layout of TreeView.
>> A solution would be to break the loop when `cell` is current cell being layouted, so that at least the layout of next cells is not performed twice.
>> 
>> Can there be a way to avoid re-layout of previous cells, too ? ?
>
> Also noticed a scenario: When a TreeCell with disclosureNode is currently not shown on screen but becomes visible on scrolling. In that case the TreeCells are layout while the scroll is in progress. I see only one way to avoid this that maxDisclosureWidthMap should reflect the correct value before starting the layout.

Yes true,
the default value of the `defaultDisclosureWidth` when there is no disclosureNode is 18 and when we come across a TreeCell that has a disclosure node the `defaultDisclosureWidth` changes to 20 that is what causes the TreeCells to move visually.
My first thought was to change the default value as that would avoid doing the re-layout and would reflect the the correct value before starting the layout also visually we won't see that change in the TreeCells position.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089122257

From angorya at openjdk.org  Wed May 14 15:16:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 May 2025 15:16:59 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
Message-ID: <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>

On Wed, 14 May 2025 14:43:05 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Also noticed a scenario: When a TreeCell with disclosureNode is currently not shown on screen but becomes visible on scrolling. In that case the TreeCells are layout while the scroll is in progress. I see only one way to avoid this that maxDisclosureWidthMap should reflect the correct value before starting the layout.
>
> Yes true,
> the default value of the `defaultDisclosureWidth` when there is no disclosureNode is 18 and when we come across a TreeCell that has a disclosure node the `defaultDisclosureWidth` changes to 20 that is what causes the TreeCells to move visually.
> My first thought was to change the default value as that would avoid doing the re-layout and would reflect the the correct value before starting the layout also visually we won't see that change in the TreeCells position.

> In that case the TreeCells are layout while the scroll is in progress.

does this create any visual artifacts?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089188397

From zelmidaoui at openjdk.org  Wed May 14 15:19:59 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 14 May 2025 15:19:59 GMT
Subject: Integrated: 8089080: [TextArea] Caret disappear after pressing
 backspace to clear the content
In-Reply-To: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
References: <WamP3kBjbzO8mlUj8trzwpaO_E9GjN7bIMw-IGa_2BY=.9978ff78-1d76-4543-995b-519a12f0a413@github.com>
Message-ID: <bLU0LcBAjskqzArKLDm7jILfUk4laVzUz8O5-IUowtk=.63726b91-400d-46b1-847e-64f3bec5db11@github.com>

On Mon, 21 Apr 2025 15:42:20 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Fixed Caret disappear after unfocus then focus on the TextArea, the issue was happening because the caret position was set to -1 when we focus on the TextArea with empty text and caused the caret to disappear from at the skin level when the position is set to -1

This pull request has now been integrated.

Changeset: 2b2355eb
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2b2355eb659cd433931825e8c0b7fa89da17e2d5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8089080: [TextArea] Caret disappear after pressing backspace to clear the content

Reviewed-by: kizune, angorya

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

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

From mfox at openjdk.org  Wed May 14 15:36:07 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 14 May 2025 15:36:07 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
Message-ID: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>

Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.

This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into keyman
 - Routing insertText character to KeyEvents for Keyman input method

Changes: https://git.openjdk.org/jfx/pull/1805/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356652
  Stats: 33 lines in 4 files changed: 27 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1805.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1805/head:pull/1805

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

From arapte at openjdk.org  Wed May 14 16:42:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 14 May 2025 16:42:59 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
Message-ID: <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>

On Wed, 14 May 2025 15:14:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> does this create any visual artifacts?

No artifacts, just that one can notice the re-layout and the TreeCell shift to right.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089341995

From angorya at openjdk.org  Wed May 14 17:30:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 May 2025 17:30:56 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
Message-ID: <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>

On Wed, 14 May 2025 16:40:36 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>>> In that case the TreeCells are layout while the scroll is in progress.
>> 
>> does this create any visual artifacts?
>
>> does this create any visual artifacts?
> 
> No artifacts, just that one can notice the re-layout and the TreeCell shift to right.

this is the expected behavior though, right?

what we **don't** want is the flicker - when the re-layout is needed but happens in another pulse.  When e.g. scrollbars need to appear/disappear it may even lead to flicker that does not end.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089414343

From zelmidaoui at openjdk.org  Wed May 14 18:28:54 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 14 May 2025 18:28:54 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
Message-ID: <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>

On Wed, 14 May 2025 17:27:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> does this create any visual artifacts?
>> 
>> No artifacts, just that one can notice the re-layout and the TreeCell shift to right.
>
> this is the expected behavior though, right?
> 
> what we **don't** want is the flicker - when the re-layout is needed but happens in another pulse.  When e.g. scrollbars need to appear/disappear it may even lead to flicker that does not end.

Yes normally it is expected to see this behavior since we do a re-layout so the TreeCells are updated with a new `defaultDisclosureWidth` value, I tested it and I do not see a flicker on my system.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2089508605

From angorya at openjdk.org  Wed May 14 20:35:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 May 2025 20:35:57 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <3VOHjSJajn9UzAumworCXeH_rQXfaoWdX3YY9T4j6v4=.9a7a214a-830c-41ab-8582-41c1496e3388@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

Reviewers: @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2881493013

From mstrauss at openjdk.org  Wed May 14 23:05:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 14 May 2025 23:05:35 GMT
Subject: RFR: 8357004: Windows platform color changes are not picked up in some
 cases
Message-ID: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>

The platform preferences API does not pick up the correct `UIColor` values when changing from a high-contrast Windows theme to another high-contrast theme.

The reason is that the implementation incorrectly assumes that changing the high-contrast theme does not affect the `UIColor` values. The fix is simple: when we query the `SysColor` values, we also need to query the `UIColor` values.

To reproduce: open platform preferences monitor in MonkeyTester (Tools -> Platform Preferences Monitor). Then switch between different high-contrast themes in Windows Settings and observe the `Windows.UIColor.*` values.

This fix can only be tested manually, since it requires interacting with the Windows OS in non-automatable ways.

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

Commit messages:
 - fix: changed UIColors are not picked up in some cases

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

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

From kizune at openjdk.org  Thu May 15 04:45:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 May 2025 04:45:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <IRaJRSIS7JEK5Vo5e_TAeziVzcK-KOmbVlZcLuEc0sA=.cdc4210e-8d39-48b4-a9a4-f0867ee9b7cd@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

Looks reasonable.

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

Marked as reviewed by kizune (Author).

PR Review: https://git.openjdk.org/jfx/pull/1805#pullrequestreview-2842201496

From arapte at openjdk.org  Thu May 15 07:09:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 15 May 2025 07:09:58 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
 <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
Message-ID: <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>

On Wed, 14 May 2025 18:26:23 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> this is the expected behavior though, right?
>> 
>> what we **don't** want is the flicker - when the re-layout is needed but happens in another pulse.  When e.g. scrollbars need to appear/disappear it may even lead to flicker that does not end.
>
> Yes normally it is expected to see this behavior since we do a re-layout so the TreeCells are updated with a new `defaultDisclosureWidth` value, I tested it and I do not see a flicker on my system.

> This would perform a layout of all cells, re-layout of previous cells and layout of next cells. but, layout of next cells is performed again as continuation layout of TreeView. A solution would be to break the loop when `cell` is current cell being layouted, so that at least the layout of next cells is not performed twice.

Would it be possible to avoid re-layout of the cells that are after the Cell with a disclosureNode ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2090441312

From lkostyra at openjdk.org  Thu May 15 11:33:06 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 15 May 2025 11:33:06 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage should
 only load that specific level
Message-ID: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>

This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.

`loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.

Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

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

Commit messages:
 - Add ImageStorage test
 - Add support for requesting specific scaling

Changes: https://git.openjdk.org/jfx/pull/1809/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1809&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342530
  Stats: 68 lines in 4 files changed: 60 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1809.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1809/head:pull/1809

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

From lkostyra at openjdk.org  Thu May 15 11:38:55 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 15 May 2025 11:38:55 GMT
Subject: RFR: 8357004: Windows platform color changes are not picked up in
 some cases
In-Reply-To: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
References: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
Message-ID: <U8iBOYTnY4v7sHqUrGTu352FgCh2f7wROtXM_KD4sCE=.0bcf108a-c27a-4a8e-bd7a-6942d59a2da3@github.com>

On Wed, 14 May 2025 23:00:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The platform preferences API does not pick up the correct `UIColor` values when changing from a high-contrast Windows theme to another high-contrast theme.
> 
> The reason is that the implementation incorrectly assumes that changing the high-contrast theme does not affect the `UIColor` values. The fix is simple: when we query the `SysColor` values, we also need to query the `UIColor` values.
> 
> To reproduce: open platform preferences monitor in MonkeyTester (Tools -> Platform Preferences Monitor). Then switch between different high-contrast themes in Windows Settings and observe the `Windows.UIColor.*` values.
> 
> This fix can only be tested manually, since it requires interacting with the Windows OS in non-automatable ways.

LGTM, the fix works as intended

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1806#pullrequestreview-2843363535

From zelmidaoui at openjdk.org  Thu May 15 11:52:56 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 15 May 2025 11:52:56 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
 <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
 <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>
Message-ID: <rB3h0-sPbAPDljIAaN8AmL-wVLxZ2GT4Rls2JyplCe8=.c08b89bd-2484-4b66-b047-dbcf038b65e8@github.com>

On Thu, 15 May 2025 07:07:07 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Would it be possible to avoid re-layout of the cells that are after the Cell with a disclosureNode ?

This is actually what is happening, when we scroll down and find a TreeCell that has a disclosure node this is when the condition `disclosureWidth > defaultDisclosureWidth` is true and we do a re-layout of the visible previous cells before the disclosure node and the new value is saved in the `maxDisclosureWidthMap` so the cells that are layouted after the disclosure node when scrolling are using the new value of `defaultDisclosureWidth`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2090990731

From angorya at openjdk.org  Thu May 15 15:26:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 15:26:02 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <sV1kw0dWMhpCyjdhqVmzdK2zx5RYruTfGDr7RUJwJDo=.03389944-d64a-45f6-9f65-f6a9daf883a4@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

What's interesting, not all Hebrew keys produce Latin text.  For example, 'f' key does generate `??` as expected (without the fix).  Is that the situation described by the comment

// Longer strings are sent out above as commits.

?

With the fix, both keyman and standard macOS text input work (including Japanese IME popup).

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884222490

From mmack at openjdk.org  Thu May 15 15:40:03 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 15 May 2025 15:40:03 GMT
Subject: RFR: 8357004: Windows platform color changes are not picked up in
 some cases
In-Reply-To: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
References: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
Message-ID: <xXYjfh1CoW55hZ3ymivYcN1aeX-jgvxhgfFEDDDxbq4=.b9e17c30-c42b-436f-8aca-84362dc35f4c@github.com>

On Wed, 14 May 2025 23:00:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The platform preferences API does not pick up the correct `UIColor` values when changing from a high-contrast Windows theme to another high-contrast theme.
> 
> The reason is that the implementation incorrectly assumes that changing the high-contrast theme does not affect the `UIColor` values. The fix is simple: when we query the `SysColor` values, we also need to query the `UIColor` values.
> 
> To reproduce: open platform preferences monitor in MonkeyTester (Tools -> Platform Preferences Monitor). Then switch between different high-contrast themes in Windows Settings and observe the `Windows.UIColor.*` values.
> 
> This fix can only be tested manually, since it requires interacting with the Windows OS in non-automatable ways.

I tested with a binding on the "Windows.UIColor.Accent" preference on Windows 11. I can reproduce this issue in master and it's fixed with this PR. Code changes only affect windows-related code and look good as well.

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

Marked as reviewed by mmack (Author).

PR Review: https://git.openjdk.org/jfx/pull/1806#pullrequestreview-2844204585

From kcr at openjdk.org  Thu May 15 15:42:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 May 2025 15:42:02 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <fD9R6YiHzhR4XhcPWc3WexTMPVqu0-9jKaj9sEUdw-4=.9862bf03-a29d-4564-b778-edb774526372@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

LGTM. All testing complete.

NOTE: The order of integration of the two PRs (AWT and JavaFX) doesn't matter. However, taking one without the other will be ineffective, so wait for both PRs to be approved before integrating either of them.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1755#pullrequestreview-2844211375

From angorya at openjdk.org  Thu May 15 15:58:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 15:58:01 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <4Flqu6xcBRn3aFpoId1jRremExp9iUOFqDYfghhvomc=.650b5b89-fd29-401b-b089-2005de12ad83@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

Noticed a bit of a problem.

To reproduce, install Himyarit Musnad keyboard https://keyman.com/keyboards/himyarit_musnad

typing 'h' causes this character to appear: ?
typing 'n' followed by 'h' generates garbage input rather than expected ?:

![Screenshot 2025-05-15 at 08 51 18](https://github.com/user-attachments/assets/5bf31611-46f9-4417-9720-f485a236c80e)

(I am using the monkey tester, but it will work with any application that uses a TextArea)

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884330689

From honkar at openjdk.org  Thu May 15 16:34:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 15 May 2025 16:34:15 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <Tdp9qgJ4yRvDT0qTCXsGqv2nCouzlXWOeEuw-2OeWSU=.18c2ec14-7a87-4931-953e-8c5d2858bd0f@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

LGTM, Both JFX + JDK fix work as expected.

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

Marked as reviewed by honkar (no project role).

PR Review: https://git.openjdk.org/jfx/pull/1755#pullrequestreview-2844362909

From mstrauss at openjdk.org  Thu May 15 16:43:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 16:43:57 GMT
Subject: Integrated: 8357004: Windows platform color changes are not picked up
 in some cases
In-Reply-To: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
References: <-o5l9PtwhXcOD1N878uX7ZHHqsxJ8tQWN-mV6tNn8f0=.12df7347-0aaa-4aa7-9c18-5e7614d1c6bc@github.com>
Message-ID: <s8rRk2u6qnvCi2PMEj1z-qSMt1R_PRtIZd2yXXYtCe8=.6ba4bb4a-5078-4819-a5f6-1e6d44df8caf@github.com>

On Wed, 14 May 2025 23:00:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The platform preferences API does not pick up the correct `UIColor` values when changing from a high-contrast Windows theme to another high-contrast theme.
> 
> The reason is that the implementation incorrectly assumes that changing the high-contrast theme does not affect the `UIColor` values. The fix is simple: when we query the `SysColor` values, we also need to query the `UIColor` values.
> 
> To reproduce: open platform preferences monitor in MonkeyTester (Tools -> Platform Preferences Monitor). Then switch between different high-contrast themes in Windows Settings and observe the `Windows.UIColor.*` values.
> 
> This fix can only be tested manually, since it requires interacting with the Windows OS in non-automatable ways.

This pull request has now been integrated.

Changeset: 10141bb7
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/10141bb7fa99ec10e2b96e8748d73d15e6271ad5
Stats:     5 lines in 2 files changed: 4 ins; 0 del; 1 mod

8357004: Windows platform color changes are not picked up in some cases

Reviewed-by: lkostyra, mmack

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

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

From kizune at openjdk.org  Thu May 15 17:28:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 15 May 2025 17:28:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <4Flqu6xcBRn3aFpoId1jRremExp9iUOFqDYfghhvomc=.650b5b89-fd29-401b-b089-2005de12ad83@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <4Flqu6xcBRn3aFpoId1jRremExp9iUOFqDYfghhvomc=.650b5b89-fd29-401b-b089-2005de12ad83@github.com>
Message-ID: <D9LElY9meolfGhbv5ey3ecGb8hH7s2Rglas__55n4XI=.77d1432e-1ba9-4f0c-9b62-f62023a38549@github.com>

On Thu, 15 May 2025 15:55:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> typing 'h' causes this character to appear: ? typing 'n' followed by 'h' generates garbage input rather than expected ?:

The same happens without the fix. For some reason events for the keys not mapped on the active keyman keyboard still pass to the component - at least partially. That affects the character composition.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884562915

From angorya at openjdk.org  Thu May 15 17:50:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 17:50:59 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <D9LElY9meolfGhbv5ey3ecGb8hH7s2Rglas__55n4XI=.77d1432e-1ba9-4f0c-9b62-f62023a38549@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <4Flqu6xcBRn3aFpoId1jRremExp9iUOFqDYfghhvomc=.650b5b89-fd29-401b-b089-2005de12ad83@github.com>
 <D9LElY9meolfGhbv5ey3ecGb8hH7s2Rglas__55n4XI=.77d1432e-1ba9-4f0c-9b62-f62023a38549@github.com>
Message-ID: <itvcye5beAr0TRg6ovV41kCEGxQB5J3vEfWSj2ygSb8=.bb862b77-0ad4-4b18-a958-efb6788df9b0@github.com>

On Thu, 15 May 2025 17:26:39 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Noticed a bit of a problem.
>> 
>> To reproduce, install Himyarit Musnad keyboard https://keyman.com/keyboards/himyarit_musnad
>> 
>> typing 'h' causes this character to appear: ?
>> typing 'n' followed by 'h' generates garbage input rather than expected ?:
>> 
>> ![Screenshot 2025-05-15 at 08 51 18](https://github.com/user-attachments/assets/5bf31611-46f9-4417-9720-f485a236c80e)
>> 
>> (I am using the monkey tester, but it will work with any application that uses a TextArea)
>
>> typing 'h' causes this character to appear: ? typing 'n' followed by 'h' generates garbage input rather than expected ?:
> 
> The same happens without the fix. For some reason events for the keys not mapped on the active keyman keyboard still pass to the component - at least partially. That affects the character composition.

You are right, @azuev-java !  Looks like this is a separate bug, where the same text involving surrogate pairs is rendered differently by the TextArea:

![Screenshot 2025-05-15 at 10 48 11](https://github.com/user-attachments/assets/a3663976-2066-49aa-8773-2f5440497824)

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884616372

From angorya at openjdk.org  Thu May 15 17:53:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 17:53:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <ZzeesFvgSt4D0k2TfYcKfAtOAeIENP5zDlqUzI2lQNk=.2a107ed0-59c1-49b7-b34a-11fe12c6a65f@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

The change fixes the immediate problem with keyman, I'll create a separate ticket for the rendering bug.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1805#pullrequestreview-2844560408

From mstrauss at openjdk.org  Thu May 15 17:55:12 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 17:55:12 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
Message-ID: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>

Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):


changed:
	Windows.UIColor.Accent=0x0078d4ff
	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
	Windows.SysColor.COLOR_WINDOW=0xffffffff
	Windows.UIColor.AccentLight1=0x0091f8ff
	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
	Windows.UIColor.Foreground=0x000000ff
	Windows.UIColor.AccentDark1=0x0067c0ff
	Windows.UIColor.Background=0xffffffff
	Windows.UIColor.AccentLight3=0x99ebffff
	Windows.UIColor.AccentLight2=0x4cc2ffff
	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
	Windows.UIColor.AccentDark2=0x003e92ff
	Windows.UIColor.AccentDark3=0x001a68ff

changed:
	-Windows.SPI.HighContrastColorScheme
	Windows.SPI.HighContrast=false

changed:
	Windows.UIColor.Foreground=0xffffffff
	Windows.UIColor.Background=0x000000ff


Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.

This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.

In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.

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

Commit messages:
 - add delayed change aggregation

Changes: https://git.openjdk.org/jfx/pull/1810/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357067
  Stats: 319 lines in 13 files changed: 282 ins; 1 del; 36 mod
  Patch: https://git.openjdk.org/jfx/pull/1810.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1810/head:pull/1810

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

From mstrauss at openjdk.org  Thu May 15 17:56:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 17:56:59 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level
In-Reply-To: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
Message-ID: <ebrUuRpwVylGyr2Lp4WOPAv4lhz8cdf-66HS5jjejw0=.2f2dd130-62ea-4790-8d3b-beb88751636b@github.com>

On Thu, 15 May 2025 11:27:21 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
> 
> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
> 
> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

Looks good.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1809#pullrequestreview-2844567664

From angorya at openjdk.org  Thu May 15 18:15:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 18:15:56 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
Message-ID: <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>

On Thu, 15 May 2025 17:50:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
> 
> 
> changed:
> 	Windows.UIColor.Accent=0x0078d4ff
> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
> 	Windows.UIColor.AccentLight1=0x0091f8ff
> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
> 	Windows.UIColor.Foreground=0x000000ff
> 	Windows.UIColor.AccentDark1=0x0067c0ff
> 	Windows.UIColor.Background=0xffffffff
> 	Windows.UIColor.AccentLight3=0x99ebffff
> 	Windows.UIColor.AccentLight2=0x4cc2ffff
> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
> 	Windows.UIColor.AccentDark2=0x003e92ff
> 	Windows.UIColor.AccentDark3=0x001a68ff
> 
> changed:
> 	-Windows.SPI.HighContrastColorScheme
> 	Windows.SPI.HighContrast=false
> 
> changed:
> 	Windows.UIColor.Foreground=0xffffffff
> 	Windows.UIColor.Background=0x000000ff
> 
> 
> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
> 
> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
> 
> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 87:

> 85:         public void handleQuitAction(Application app, long time) {
> 86:         }
> 87:         public void handlePreferencesChanged(Map<String, Object> preferences, int suggestedDelayMillis) {

I wonder if we should always debounce the changes with a short delay?
A delay of 100-150 ms will be acceptable from the user perspective.
What do you think?

modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.h line 75:

> 73:      * Suggested aggregation delay for changes that come in over a period of time.
> 74:      */
> 75:     static constexpr int SUGGESTED_DELAY_MILLIS = 1000;

1 second seems too long.
What is the typical range for the high contrast train of changes?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091729799
PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091733037

From mstrauss at openjdk.org  Thu May 15 18:31:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 18:31:55 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
Message-ID: <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>

On Thu, 15 May 2025 18:13:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
>> 
>> 
>> changed:
>> 	Windows.UIColor.Accent=0x0078d4ff
>> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
>> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
>> 	Windows.UIColor.AccentLight1=0x0091f8ff
>> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
>> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
>> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
>> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
>> 	Windows.UIColor.Foreground=0x000000ff
>> 	Windows.UIColor.AccentDark1=0x0067c0ff
>> 	Windows.UIColor.Background=0xffffffff
>> 	Windows.UIColor.AccentLight3=0x99ebffff
>> 	Windows.UIColor.AccentLight2=0x4cc2ffff
>> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
>> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
>> 	Windows.UIColor.AccentDark2=0x003e92ff
>> 	Windows.UIColor.AccentDark3=0x001a68ff
>> 
>> changed:
>> 	-Windows.SPI.HighContrastColorScheme
>> 	Windows.SPI.HighContrast=false
>> 
>> changed:
>> 	Windows.UIColor.Foreground=0xffffffff
>> 	Windows.UIColor.Background=0x000000ff
>> 
>> 
>> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
>> 
>> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
>> 
>> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.
>
> modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.h line 75:
> 
>> 73:      * Suggested aggregation delay for changes that come in over a period of time.
>> 74:      */
>> 75:     static constexpr int SUGGESTED_DELAY_MILLIS = 1000;
> 
> 1 second seems too long.
> What is the typical range for the high contrast train of changes?

Quite a lot, Windows takes around 1-2 seconds to change to and from a high-contrast theme (there's even a full-frame wait screen that pops up). The suggested delay of 1 second works reliably on my machine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091755001

From mstrauss at openjdk.org  Thu May 15 18:37:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 18:37:57 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
Message-ID: <lMavuY2Es5szg1NWq05TRgSNlT1eJ4nX3dlCr4tSRr8=.bd0cac2d-f82e-4a24-b13d-c61cccd0d0ee@github.com>

On Thu, 15 May 2025 18:11:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
>> 
>> 
>> changed:
>> 	Windows.UIColor.Accent=0x0078d4ff
>> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
>> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
>> 	Windows.UIColor.AccentLight1=0x0091f8ff
>> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
>> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
>> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
>> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
>> 	Windows.UIColor.Foreground=0x000000ff
>> 	Windows.UIColor.AccentDark1=0x0067c0ff
>> 	Windows.UIColor.Background=0xffffffff
>> 	Windows.UIColor.AccentLight3=0x99ebffff
>> 	Windows.UIColor.AccentLight2=0x4cc2ffff
>> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
>> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
>> 	Windows.UIColor.AccentDark2=0x003e92ff
>> 	Windows.UIColor.AccentDark3=0x001a68ff
>> 
>> changed:
>> 	-Windows.SPI.HighContrastColorScheme
>> 	Windows.SPI.HighContrast=false
>> 
>> changed:
>> 	Windows.UIColor.Foreground=0xffffffff
>> 	Windows.UIColor.Background=0x000000ff
>> 
>> 
>> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
>> 
>> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
>> 
>> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 87:
> 
>> 85:         public void handleQuitAction(Application app, long time) {
>> 86:         }
>> 87:         public void handlePreferencesChanged(Map<String, Object> preferences, int suggestedDelayMillis) {
> 
> I wonder if we should always debounce the changes with a short delay?
> A delay of 100-150 ms will be acceptable from the user perspective.
> What do you think?

Most changed settings are not correlated with other settings, so no waiting is necessary (for example, we wouldn't wait after a `reducedMotion` change). We only need to wait a bit when a single user-facing setting can affect several correlated preferences. This only seems to be the case on Windows, and only when changing high-contrast themes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091760658

From angorya at openjdk.org  Thu May 15 18:37:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 18:37:58 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
Message-ID: <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>

On Thu, 15 May 2025 18:28:59 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.h line 75:
>> 
>>> 73:      * Suggested aggregation delay for changes that come in over a period of time.
>>> 74:      */
>>> 75:     static constexpr int SUGGESTED_DELAY_MILLIS = 1000;
>> 
>> 1 second seems too long.
>> What is the typical range for the high contrast train of changes?
>
> Quite a lot, Windows takes around 1-2 seconds to change to and from a high-contrast theme (there's even a full-frame wait screen that pops up). The suggested delay of 1 second works reliably on my machine.

If it takes that long to update all the colors, maybe we should not add complexity to this subsystem and just send the events as they come?

What exactly is the problem the user experiences right now?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091764273

From mstrauss at openjdk.org  Thu May 15 18:52:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 18:52:55 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
 <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
Message-ID: <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>

On Thu, 15 May 2025 18:35:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Quite a lot, Windows takes around 1-2 seconds to change to and from a high-contrast theme (there's even a full-frame wait screen that pops up). The suggested delay of 1 second works reliably on my machine.
>
> If it takes that long to update all the colors, maybe we should not add complexity to this subsystem and just send the events as they come?
> 
> What exactly is the problem the user experiences right now?

A single user-facing setting change should only result in a single change notification in JavaFX, as that's what developers would intuitively expect. I'm planning to add support for CSS system colors soon, which basically exposes platform colors to stylesheet authors. When the color palette changes, I want all changes to be applied at the same time and not piece by piece.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091784263

From mstrauss at openjdk.org  Thu May 15 18:56:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 18:56:14 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
Message-ID: <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>

> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
> 
> 
> changed:
> 	Windows.UIColor.Accent=0x0078d4ff
> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
> 	Windows.UIColor.AccentLight1=0x0091f8ff
> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
> 	Windows.UIColor.Foreground=0x000000ff
> 	Windows.UIColor.AccentDark1=0x0067c0ff
> 	Windows.UIColor.Background=0xffffffff
> 	Windows.UIColor.AccentLight3=0x99ebffff
> 	Windows.UIColor.AccentLight2=0x4cc2ffff
> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
> 	Windows.UIColor.AccentDark2=0x003e92ff
> 	Windows.UIColor.AccentDark3=0x001a68ff
> 
> changed:
> 	-Windows.SPI.HighContrastColorScheme
> 	Windows.SPI.HighContrast=false
> 
> changed:
> 	Windows.UIColor.Foreground=0xffffffff
> 	Windows.UIColor.Background=0x000000ff
> 
> 
> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
> 
> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
> 
> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.

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

  simplified DelayedChangedAggregator

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1810/files
  - new: https://git.openjdk.org/jfx/pull/1810/files/a512dc4d..8fce572c

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

  Stats: 77 lines in 3 files changed: 15 ins; 25 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1810.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1810/head:pull/1810

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

From angorya at openjdk.org  Thu May 15 19:02:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 19:02:55 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
Message-ID: <lSGA9zf1rfoJInPJUYwlynwUAYyrONFRPpifQHwzEPY=.b7b98b20-6f08-4562-b461-35aab5b0176a@github.com>

On Thu, 15 May 2025 18:56:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
>> 
>> 
>> changed:
>> 	Windows.UIColor.Accent=0x0078d4ff
>> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
>> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
>> 	Windows.UIColor.AccentLight1=0x0091f8ff
>> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
>> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
>> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
>> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
>> 	Windows.UIColor.Foreground=0x000000ff
>> 	Windows.UIColor.AccentDark1=0x0067c0ff
>> 	Windows.UIColor.Background=0xffffffff
>> 	Windows.UIColor.AccentLight3=0x99ebffff
>> 	Windows.UIColor.AccentLight2=0x4cc2ffff
>> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
>> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
>> 	Windows.UIColor.AccentDark2=0x003e92ff
>> 	Windows.UIColor.AccentDark3=0x001a68ff
>> 
>> changed:
>> 	-Windows.SPI.HighContrastColorScheme
>> 	Windows.SPI.HighContrast=false
>> 
>> changed:
>> 	Windows.UIColor.Foreground=0xffffffff
>> 	Windows.UIColor.Background=0x000000ff
>> 
>> 
>> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
>> 
>> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
>> 
>> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified DelayedChangedAggregator

I am not comfortable with this change, as it falls under application requirements.

The function of the JavaFX platform is to communicate the OS events as faithfully as it can, in my opinion.  If the application requirements call for some debouncing, especially that with a one second delay, then the application is free to implement that.

If, however, the application requirements call for no delay, this change makes it impossible.

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

PR Comment: https://git.openjdk.org/jfx/pull/1810#issuecomment-2884795670

From mfox at openjdk.org  Thu May 15 19:06:56 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 15 May 2025 19:06:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

The N key in the Himyarit Musnad layout shouldn't generate a character (just a beep). Under the hood glass is seeing a keyDown: event for the N key (same as it would for a U.S. English layout) so it generates a KeyEvent. I can't figure out a good way of avoiding this, any fix I can think of would also affect keys like Tab  where we *have* to generate a KeyEvent. I'll continue to think about this but for now this PR gets Keyman working at some minimal level and I have my doubts that we can do much better.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884805897

From angorya at openjdk.org  Thu May 15 19:13:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 19:13:54 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <_wSrBNFAsRmf4biLHZUAZufKDiG1KtfWK2k8iICXqSo=.b506b26b-9c5f-4dfa-a017-788408cbca23@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

Created https://bugs.openjdk.org/browse/JDK-8357070 for the rendering bug.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2884820303

From mstrauss at openjdk.org  Thu May 15 19:18:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 19:18:56 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <lSGA9zf1rfoJInPJUYwlynwUAYyrONFRPpifQHwzEPY=.b7b98b20-6f08-4562-b461-35aab5b0176a@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
 <lSGA9zf1rfoJInPJUYwlynwUAYyrONFRPpifQHwzEPY=.b7b98b20-6f08-4562-b461-35aab5b0176a@github.com>
Message-ID: <VTE1TROGrMEtesJCQLJvbfC3DFsCBNLy4GUhlTZ4cJo=.dadd2e68-550d-41ed-a278-fd7cd5db0985@github.com>

On Thu, 15 May 2025 19:00:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I am not comfortable with this change, as it falls under application requirements.
> 
> The function of the JavaFX platform is to communicate the OS events as faithfully as it can, in my opinion. If the application requirements call for some debouncing, especially that with a one second delay, then the application is free to implement that.

The platform preferences API is an abstraction, and nowhere do we specify that it replicates the exact stream of OS events. What we _do_ (implicitly) specify, however, is that the observable state of platform preferences accurately reflects the OS settings. Do you really think that it is okay for an application to be able to observe inconsistent transient states? In this example, applications can observe inconsistent `foregroundColor` and `backgroundColor` values.

> If, however, the application requirements call for no delay, this change makes it impossible.

An application can require all it wants, but "inconsistent transient states are okay" is not an acceptable trade-off. There's no delay for uncorrelated changes, which is as good as it gets.

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

PR Comment: https://git.openjdk.org/jfx/pull/1810#issuecomment-2884831530

From mmack at openjdk.org  Thu May 15 19:35:55 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 15 May 2025 19:35:55 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
Message-ID: <qyBrKvqDWSmtvUA27LOGeGbHyB547ALccaYbA9oG-n8=.f26e4924-b729-4e39-a161-476996690f1a@github.com>

On Thu, 15 May 2025 18:56:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
>> 
>> 
>> changed:
>> 	Windows.UIColor.Accent=0x0078d4ff
>> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
>> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
>> 	Windows.UIColor.AccentLight1=0x0091f8ff
>> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
>> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
>> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
>> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
>> 	Windows.UIColor.Foreground=0x000000ff
>> 	Windows.UIColor.AccentDark1=0x0067c0ff
>> 	Windows.UIColor.Background=0xffffffff
>> 	Windows.UIColor.AccentLight3=0x99ebffff
>> 	Windows.UIColor.AccentLight2=0x4cc2ffff
>> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
>> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
>> 	Windows.UIColor.AccentDark2=0x003e92ff
>> 	Windows.UIColor.AccentDark3=0x001a68ff
>> 
>> changed:
>> 	-Windows.SPI.HighContrastColorScheme
>> 	Windows.SPI.HighContrast=false
>> 
>> changed:
>> 	Windows.UIColor.Foreground=0xffffffff
>> 	Windows.UIColor.Background=0x000000ff
>> 
>> 
>> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
>> 
>> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
>> 
>> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplified DelayedChangedAggregator

I'm in favor of abstracting this away as good as possible, i.e. trying to aggregate such events if some sufficiently universal timing parameters (or something better than time-based logic) can be found. As an application developer I often choose javafx especially because it keeps OS-implementation dependent behavior to a minimum and reduces the likelihood of me "using things the wrong way", like having inconsistent states that might need to be handled.  And who knows what the next version of windows will do...

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

PR Comment: https://git.openjdk.org/jfx/pull/1810#issuecomment-2884867051

From jhendrikx at openjdk.org  Thu May 15 20:17:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 15 May 2025 20:17:59 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level
In-Reply-To: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
Message-ID: <wPlStIhdS9KUtTcJNpk4YpwaIuqxFXl-SntxYHpAKss=.1d6e92ff-c0e9-4dee-b26e-2a047a3b76cb@github.com>

On Thu, 15 May 2025 11:27:21 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
> 
> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
> 
> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

Changes requested by jhendrikx (Reviewer).

modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 166:

> 164:         return true;
> 165:     }
> 166: 

1. Is looking for a slash going to be compatible on all platforms?  Where is the path string coming from?
2. Catching `NumberFormatException` to "check" if something is a number is bad form
3. It will allow `@0x` and `@-1x` etc...
4. Consider using a regular expression, it is much more concise and intended for this kind of matching

Here's a regular expression for this:

    Pattern SCALED_PATTERN = Pattern.compile(".*@[1-9][0-9]?x(\.[^\.]+)?");
    
The above will match any path that ends with `@` followed by a number from 1 to 99, followed by an `x`, optionally followed by an extension that does not contain a dot.  No need to check for slashes.

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

PR Review: https://git.openjdk.org/jfx/pull/1809#pullrequestreview-2844864600
PR Review Comment: https://git.openjdk.org/jfx/pull/1809#discussion_r2091889766

From prr at openjdk.org  Thu May 15 20:19:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 May 2025 20:19:00 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <wu1OGIKg1koeRkczr4xTFUCOBc3M-K4yOjkuS7Pji30=.ab22bf66-8f15-424d-8e5e-ab42ef3879d3@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

The JDK bug https://bugs.openjdk.org/browse/JDK-8332947 says this used to work on macOS 13.x but was broken by new requirements on 14.x ... it isn't spelled out enough for me to understand. Did it really used to work ?

Also today, FX has nothing that allows an app to  handle these events - ie no Desktop class.
if/when it does, then I presume that if ALSO the FX has registered to handle these events that in such a case FX would not forward them to FX.

Also if/when FX has a way to handle these events, wouldn't you want AWT to do the same .. and pass them on to FX if no AWT handler is registered ?

And its a bit more complicated then than "I'm the hosting toolkit, so I don't forward", there needs to be some check for the app having registered a handler.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2884954496

From jhendrikx at openjdk.org  Thu May 15 20:21:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 15 May 2025 20:21:58 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level
In-Reply-To: <wPlStIhdS9KUtTcJNpk4YpwaIuqxFXl-SntxYHpAKss=.1d6e92ff-c0e9-4dee-b26e-2a047a3b76cb@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <wPlStIhdS9KUtTcJNpk4YpwaIuqxFXl-SntxYHpAKss=.1d6e92ff-c0e9-4dee-b26e-2a047a3b76cb@github.com>
Message-ID: <RJJLvgkAuDqsLEy_OXIMSsFSsHO4i7VHTsC6nnWqZrs=.3edf08ac-d8f7-4eb7-84db-a2bf4684a69b@github.com>

On Thu, 15 May 2025 20:10:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 166:
> 
>> 164:         return true;
>> 165:     }
>> 166: 
> 
> 1. Is looking for a slash going to be compatible on all platforms?  Where is the path string coming from?
> 2. Catching `NumberFormatException` to "check" if something is a number is bad form
> 3. It will allow `@0x` and `@-1x` etc...
> 4. Consider using a regular expression, it is much more concise and intended for this kind of matching
> 
> Here's a regular expression for this:
> 
>     Pattern SCALED_PATTERN = Pattern.compile(".*@[1-9][0-9]?x(\.[^\.]+)?");
>     
> The above will match any path that ends with `@` followed by a number from 1 to 99, followed by an `x`, optionally followed by an extension that does not contain a dot.  No need to check for slashes.

If you want you can even return the scale with a slightly altered pattern:

     private static final Pattern SCALED_PATTERN = Pattern.compile(".*@([1-9][0-9]?)x(?:\.[^\.]+)?");
     
Then do:

     Matcher matcher = SCALED_PATTERN.matcher(path);
     
     if (matcher.matches()) {
          return Integer.parseInt(matcher.group(1));  // can't throw NumberFormatException, number is validated by pattern
     }
     
     return 0;  // there was no scale

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1809#discussion_r2091898708

From jhendrikx at openjdk.org  Thu May 15 20:27:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 15 May 2025 20:27:54 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
 <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
 <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>
Message-ID: <jvN_AvIGBzFm_VZt8W35TRVCAJYfh7_MlwSxvZaToyQ=.2052e0b6-b043-4e5f-b6fd-a894ae9f4345@github.com>

On Thu, 15 May 2025 18:50:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> If it takes that long to update all the colors, maybe we should not add complexity to this subsystem and just send the events as they come?
>> 
>> What exactly is the problem the user experiences right now?
>
> A single user-facing setting change should only result in a single change notification in JavaFX, as that's what developers would intuitively expect. I'm planning to add support for CSS system colors soon, which basically exposes platform colors to stylesheet authors. When the color palette changes, I want all changes to be applied at the same time and not piece by piece.

Are you sure a delay is a good way to solve this?  It won't guarantee that no inconsistent states will be observed (what if Windows is slower, or a change is reverted within the delay period -- you may still see "half" changes).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091908691

From duke at openjdk.org  Thu May 15 20:35:59 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 15 May 2025 20:35:59 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <DD54dWCqHuIco4xrBe9GNmepV1f99O7uMTljSjlEiWc=.ca239af6-7e41-4f89-a8b0-b6cdbff79a6a@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

Interesting feedback.

I was told that it did work on an older version, but I don't remember if I tested it or not. Apparently MacOS changed something in their event handling logic from one version to another so that only one event handler could be registered at a time.

If JavaFX would have its own Desktop class, then the NativeEvent handler would not need to forward those events anymore, as FX would handle it.

If JavaFX would handle some events that AWT doesn't, then I guess it would make sense to also allow AWT to send native events. Since I didn't found any such events yet, I didn't look into it.

I don't understand Your last point. If no event handler is registered, JavaFX still forwards them, but they won't do anything unless a handler is registered at some point. So what exactly do You mean?

So is there something You want me to do in the code?
Or did I answer Your questions?

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2884989531

From jhendrikx at openjdk.org  Thu May 15 20:36:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 15 May 2025 20:36:59 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <VTE1TROGrMEtesJCQLJvbfC3DFsCBNLy4GUhlTZ4cJo=.dadd2e68-550d-41ed-a278-fd7cd5db0985@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <_XiE36zDtAN0nd3xebwfqLH8GbDNed7vF9wiDz-ai4M=.fd8e9f75-feab-42d0-a9ff-df1b43552538@github.com>
 <lSGA9zf1rfoJInPJUYwlynwUAYyrONFRPpifQHwzEPY=.b7b98b20-6f08-4562-b461-35aab5b0176a@github.com>
 <VTE1TROGrMEtesJCQLJvbfC3DFsCBNLy4GUhlTZ4cJo=.dadd2e68-550d-41ed-a278-fd7cd5db0985@github.com>
Message-ID: <CXdRKiQdrYUC4q24S5ZQ7lsZHvchEFjUYQZnAnZl0sk=.eb51e23d-ac95-42b7-9f09-2e518f0fa851@github.com>

On Thu, 15 May 2025 19:16:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I am not comfortable with this change, as it falls under application requirements.
> 
> The function of the JavaFX platform is to communicate the OS events as faithfully as it can, in my opinion

The function of JavaFX is to abstract the platform it runs on, preferably in such a way that one can't distinguish between platforms at all, just like about every other API the JDK offers (ie. NIO, Threads, Swing, etc).  This is one of the reasons we don't expose window handles or DirectX/GL API's to users.

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

PR Comment: https://git.openjdk.org/jfx/pull/1810#issuecomment-2884993238

From mstrauss at openjdk.org  Thu May 15 20:37:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 20:37:00 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <jvN_AvIGBzFm_VZt8W35TRVCAJYfh7_MlwSxvZaToyQ=.2052e0b6-b043-4e5f-b6fd-a894ae9f4345@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
 <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
 <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>
 <jvN_AvIGBzFm_VZt8W35TRVCAJYfh7_MlwSxvZaToyQ=.2052e0b6-b043-4e5f-b6fd-a894ae9f4345@github.com>
Message-ID: <mC69HEODf0pf3n8e4NJ1q3DGytAoGykVjyTrYBjtYLg=.3a28abf5-ddba-494b-86f3-e786e72ca228@github.com>

On Thu, 15 May 2025 20:25:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> A single user-facing setting change should only result in a single change notification in JavaFX, as that's what developers would intuitively expect. I'm planning to add support for CSS system colors soon, which basically exposes platform colors to stylesheet authors. When the color palette changes, I want all changes to be applied at the same time and not piece by piece.
>
> Are you sure a delay is a good way to solve this?  It won't guarantee that no inconsistent states will be observed (what if Windows is slower, or a change is reverted within the delay period -- you may still see "half" changes).

I don't think that there's a perfect way to solve this. Yes, this can theoretically happen, and then you'll see a visual glitch. I can imagine that this might also be the reason why Windows shows a full-screen popup when you switch to and from a high-contrast theme: to hide glitchy applications during the transition period.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091919919

From jhendrikx at openjdk.org  Thu May 15 20:45:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 15 May 2025 20:45:59 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <mC69HEODf0pf3n8e4NJ1q3DGytAoGykVjyTrYBjtYLg=.3a28abf5-ddba-494b-86f3-e786e72ca228@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
 <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
 <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>
 <jvN_AvIGBzFm_VZt8W35TRVCAJYfh7_MlwSxvZaToyQ=.2052e0b6-b043-4e5f-b6fd-a894ae9f4345@github.com>
 <mC69HEODf0pf3n8e4NJ1q3DGytAoGykVjyTrYBjtYLg=.3a28abf5-ddba-494b-86f3-e786e72ca228@github.com>
Message-ID: <CuEeAA2WDFVXZfAVfm_dg3fbukq9VGOTdWRct4_RE_Q=.661fe3f2-43bb-477b-b385-2e91a98f5491@github.com>

On Thu, 15 May 2025 20:34:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Are you sure a delay is a good way to solve this?  It won't guarantee that no inconsistent states will be observed (what if Windows is slower, or a change is reverted within the delay period -- you may still see "half" changes).
>
> I don't think that there's a perfect way to solve this. Yes, this can theoretically happen, and then you'll see a visual glitch. I can imagine that this might also be the reason why Windows shows a full-screen popup when you switch to and from a high-contrast theme: to hide glitchy applications during the transition period.

Alright, just making sure, as you mentioned in another thread seeing inconsistent transient states isn't an acceptable trade-off.  They can still occur, and so users can't rely on them.  In that respect the situation is similar to before this change, other than it being less likely to occur (and perhaps never or rarely in practice).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091930905

From prr at openjdk.org  Thu May 15 21:17:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 May 2025 21:17:00 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <1W6Hhkd4rcvp22QMS3qCjVM0yeIgiA1oygvd8uCE7SM=.6f1dea04-8416-4dae-8cea-94f7e6925c66@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1755#pullrequestreview-2844987370

From prr at openjdk.org  Thu May 15 21:17:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 May 2025 21:17:00 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <DD54dWCqHuIco4xrBe9GNmepV1f99O7uMTljSjlEiWc=.ca239af6-7e41-4f89-a8b0-b6cdbff79a6a@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
 <DD54dWCqHuIco4xrBe9GNmepV1f99O7uMTljSjlEiWc=.ca239af6-7e41-4f89-a8b0-b6cdbff79a6a@github.com>
Message-ID: <q1x-6nbWrI0OdDjppmAihXR5sfnUVEaUeenWtRorvlo=.10048c8d-068c-4f64-b460-18fd16f07583@github.com>

On Thu, 15 May 2025 20:32:57 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> Interesting feedback.

Most of it wasn't really directed at you .. more at Kevin :-)
The main question I had for you was about did it ever really work and I guess you aren't sure.

> I don't understand Your last point. If no event handler is registered, JavaFX still forwards them, but they won't do anything unless a handler is registered at some point. So what exactly do You mean?

Well we don't expect FX to know if an AWT event handler is registered - especially one at the application level, ie via
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Desktop.html#setOpenURIHandler(java.awt.desktop.OpenURIHandler)

What I mean is that if FX acquired a similar API, and was the hosting toolkit, I would expect it to check if there was a "javafx.desktop.Desktop" URI Handler installed and forward only if that was "null". And vice versa for AWT.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2885063390

From mstrauss at openjdk.org  Thu May 15 21:20:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 May 2025 21:20:58 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v2]
In-Reply-To: <CuEeAA2WDFVXZfAVfm_dg3fbukq9VGOTdWRct4_RE_Q=.661fe3f2-43bb-477b-b385-2e91a98f5491@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
 <z3-tUVHXBcHd6bZKlTc0BhGuj_gfbLd4Xmak2PDWyTU=.a9ae3e5a-fe3f-4e8e-96d3-9952399ce56d@github.com>
 <7gsirEI8zjvfAnLfRLnNmbFHr9VERuj3mGQTUoH1dFM=.be7c5d04-2f63-40f8-af5e-de390f4408eb@github.com>
 <zXvI6Lxr91x1A-w40QqaEmD9mrfk9byRF5H4yutl2hc=.27ef7970-0b78-44a5-9731-1e9ea371ead8@github.com>
 <2bpt8zZCjWUVT0A_aKBVz8UTVFqj0Bat8G7Dd60tP0o=.13f95b3a-a933-42e4-8088-63c1248cf41e@github.com>
 <jvN_AvIGBzFm_VZt8W35TRVCAJYfh7_MlwSxvZaToyQ=.2052e0b6-b043-4e5f-b6fd-a894ae9f4345@github.com>
 <mC69HEODf0pf3n8e4NJ1q3DGytAoGykVjyTrYBjtYLg=.3a28abf5-ddba-494b-86f3-e786e72ca228@github.com>
 <CuEeAA2WDFVXZfAVfm_dg3fbukq9VGOTdWRct4_RE_Q=.661fe3f2-43bb-477b-b385-2e91a98f5491@github.com>
Message-ID: <cBKbTFReMARZhckOxgCRgByXPDRiqldB_QFaOPHzUAI=.09576b9e-5684-48da-bf13-a85221f93b0e@github.com>

On Thu, 15 May 2025 20:43:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I don't think that there's a perfect way to solve this. Yes, this can theoretically happen, and then you'll see a visual glitch. I can imagine that this might also be the reason why Windows shows a full-screen popup when you switch to and from a high-contrast theme: to hide glitchy applications during the transition period.
>
> Alright, just making sure, as you mentioned in another thread seeing inconsistent transient states isn't an acceptable trade-off.  They can still occur, and so users can't rely on them.  In that respect the situation is similar to before this change, other than it being less likely to occur (and perhaps never or rarely in practice).

Yes, I think having inconsistent transient states is not an acceptable trade-off, that's why I think reducing them by 99,9% (from guaranteed to happen, to almost hever happening) is sensible. If it does happen anyway, it shouldn't crash your application but show up as a visual glitch (I mean, we're talking about colors). In that sense, you can "rely" on it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091974093

From duke at openjdk.org  Thu May 15 21:21:02 2025
From: duke at openjdk.org (duke)
Date: Thu, 15 May 2025 21:21:02 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
Message-ID: <aOMcAzy-8j78OxBjToqWC8I8fRNEbafbkZ1efak2UPQ=.e9753134-b5ab-41a0-8607-c2dc00f214ac@github.com>

On Wed, 7 May 2025 16:41:37 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
>> Either the native menu is not shown or the URIs are not received.
>> 
>> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
>> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
>> 
>> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
>> 
>> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
>> Co-Author: @FlorianKirmaier
>> 
>> Link to the test repo: https://github.com/pabulaner/openurifx
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332947: [macos] java.awt.desktop.OpenURIHandler is not receiving events

@pabulaner 
Your change (at version 35fa7fb477a7622eec3f276e80713ba093db1a57) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2885075984

From angorya at openjdk.org  Thu May 15 22:28:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 22:28:57 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>
Message-ID: <Jrj5OsrCUg-fzBObR1bQNtgfboUQk7iIulgIQhqWD88=.9317a87d-76b2-4bac-ab33-e42b1b2cfe94@github.com>

On Thu, 15 May 2025 19:04:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The N key in the Himyarit Musnad layout shouldn't generate a character (just a beep)

Do you think it's a bug in keyman or our code?  I head the beep (correctly) but then n appears, despite the keyman onscreen keyboard showing an empty key.  If it is our code, should there be some additional logic?

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885185227

From srl at openjdk.org  Thu May 15 22:35:57 2025
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 15 May 2025 22:35:57 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <852zFvgDOfe_IA6ZqeQj9WNkzgpQsplz4wkPsqiE7zs=.7469e93e-3b88-4f05-ab16-b9d87eb670b8@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

FYI @Sgschantz ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885196312

From duke at openjdk.org  Thu May 15 22:36:00 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 15 May 2025 22:36:00 GMT
Subject: Integrated: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit
In-Reply-To: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
Message-ID: <O4vuwv4SF2PQNsUxttbYM0WONvNG8ia0f83jwdkgzXE=.0cf8cc94-6425-41cc-8d76-f59af2308c37@github.com>

On Wed, 2 Apr 2025 14:06:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
> Either the native menu is not shown or the URIs are not received.
> 
> This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
> It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.
> 
> The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.
> 
> JDK Pull Request: https://github.com/openjdk/jdk/pull/24379
> Co-Author: @FlorianKirmaier
> 
> Link to the test repo: https://github.com/pabulaner/openurifx

This pull request has now been integrated.

Changeset: 5b659f58
Author:    Paul H <p.hayder at icloud.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5b659f58e5e6d6e7a621eda538f658a7967d8c92
Stats:     20 lines in 1 file changed: 20 ins; 0 del; 0 mod

8354631: [macos] OpenURIHandler events not received by AWT when JavaFX is primary toolkit

Co-authored-by: Florian Kirmaier <fkirmaier at openjdk.org>
Reviewed-by: kcr, honkar, prr

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

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

From mfox at openjdk.org  Thu May 15 22:51:54 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 15 May 2025 22:51:54 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <Jrj5OsrCUg-fzBObR1bQNtgfboUQk7iIulgIQhqWD88=.9317a87d-76b2-4bac-ab33-e42b1b2cfe94@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>
 <Jrj5OsrCUg-fzBObR1bQNtgfboUQk7iIulgIQhqWD88=.9317a87d-76b2-4bac-ab33-e42b1b2cfe94@github.com>
Message-ID: <2kVwcFLt046wf4nWbFUp5ShoERfZupmAecz0eKurveY=.ad8cad8e-4d24-4d03-a752-bbac43f0271d@github.com>

On Thu, 15 May 2025 22:25:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Do you think it's a bug in keyman or our code? I head the beep (correctly) but then n appears, despite the keyman onscreen keyboard showing an empty key. If it is our code, should there be some additional logic?

Keyman is definitely sending us a keyDown: for the N key. I'm still trying to figure out how to ignore it without also dropping other key strokes that we need.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885217179

From srl at openjdk.org  Thu May 15 22:59:55 2025
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 15 May 2025 22:59:55 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <2kVwcFLt046wf4nWbFUp5ShoERfZupmAecz0eKurveY=.ad8cad8e-4d24-4d03-a752-bbac43f0271d@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>
 <Jrj5OsrCUg-fzBObR1bQNtgfboUQk7iIulgIQhqWD88=.9317a87d-76b2-4bac-ab33-e42b1b2cfe94@github.com>
 <2kVwcFLt046wf4nWbFUp5ShoERfZupmAecz0eKurveY=.ad8cad8e-4d24-4d03-a752-bbac43f0271d@github.com>
Message-ID: <aUiyRPtSLBZGW7jHgZIs8ohr-znNhnBUG8L1am-Vlio=.dfb4c090-d1ab-44e8-8d96-ebb631cec695@github.com>

On Thu, 15 May 2025 22:48:51 GMT, Martin Fox <mfox at openjdk.org> wrote:

>>> The N key in the Himyarit Musnad layout shouldn't generate a character (just a beep)
>> 
>> Do you think it's a bug in keyman or our code?  I head the beep (correctly) but then n appears, despite the keyman onscreen keyboard showing an empty key.  If it is our code, should there be some additional logic?
>
>> Do you think it's a bug in keyman or our code? I head the beep (correctly) but then n appears, despite the keyman onscreen keyboard showing an empty key. If it is our code, should there be some additional logic?
> 
> Keyman is definitely sending us a keyDown: for the N key. I'm still trying to figure out how to ignore it without also dropping other key strokes that we need.

@beldenfox i mentioned the mac lead who should be able to comment. 

Does the Devanagari case in https://bugs.openjdk.org/browse/JDK-8195675?focusedId=14148577&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14148577 work ? That's the one I was testing for the corresponding jdk issue

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885229156

From angorya at openjdk.org  Thu May 15 23:07:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 May 2025 23:07:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <aUiyRPtSLBZGW7jHgZIs8ohr-znNhnBUG8L1am-Vlio=.dfb4c090-d1ab-44e8-8d96-ebb631cec695@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <HuSm5AYfCDlk7Tdsj06-WDsz4JyLa39HWwoTHPLhKnc=.c7b4a61b-388b-439c-a877-96a1230b879c@github.com>
 <Jrj5OsrCUg-fzBObR1bQNtgfboUQk7iIulgIQhqWD88=.9317a87d-76b2-4bac-ab33-e42b1b2cfe94@github.com>
 <2kVwcFLt046wf4nWbFUp5ShoERfZupmAecz0eKurveY=.ad8cad8e-4d24-4d03-a752-bbac43f0271d@github.com>
 <aUiyRPtSLBZGW7jHgZIs8ohr-znNhnBUG8L1am-Vlio=.dfb4c090-d1ab-44e8-8d96-ebb631cec695@github.com>
Message-ID: <kh-Bs9wUeuepOauv3qQ7K1PlCGxhBvZ1LcPjwC1Lwcs=.9bc205ad-2c3d-4fd6-97e3-38f7dc1721b5@github.com>

On Thu, 15 May 2025 22:57:08 GMT, Steven Loomis <srl at openjdk.org> wrote:

>>> Do you think it's a bug in keyman or our code? I head the beep (correctly) but then n appears, despite the keyman onscreen keyboard showing an empty key. If it is our code, should there be some additional logic?
>> 
>> Keyman is definitely sending us a keyDown: for the N key. I'm still trying to figure out how to ignore it without also dropping other key strokes that we need.
>
> @beldenfox i mentioned the mac lead who should be able to comment. 
> 
> Does the Devanagari case in https://bugs.openjdk.org/browse/JDK-8195675?focusedId=14148577&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14148577 work ? That's the one I was testing for the corresponding jdk issue

@srl295 
ISIS Devanagari is no longer available:
https://keyman.com/keyboards/isis_devanagari

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885238974

From kcr at openjdk.org  Thu May 15 23:46:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 May 2025 23:46:56 GMT
Subject: RFR: 8354631: [macos] OpenURIHandler events not received by AWT
 when JavaFX is primary toolkit [v2]
In-Reply-To: <q1x-6nbWrI0OdDjppmAihXR5sfnUVEaUeenWtRorvlo=.10048c8d-068c-4f64-b460-18fd16f07583@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <w8sagqYLqDZGjsSBL7HsJ9aRsX6ngL1y8hPU9HiFxJ4=.5aed2d12-5654-43fc-9694-713e3d83ece6@github.com>
 <DD54dWCqHuIco4xrBe9GNmepV1f99O7uMTljSjlEiWc=.ca239af6-7e41-4f89-a8b0-b6cdbff79a6a@github.com>
 <q1x-6nbWrI0OdDjppmAihXR5sfnUVEaUeenWtRorvlo=.10048c8d-068c-4f64-b460-18fd16f07583@github.com>
Message-ID: <1layKyNjKrkhuwDvRxlF5pxZAAOTGxlF6UN-UOnbvls=.3c430d70-e1b9-4716-8406-6dd93d0f3bfa@github.com>

On Thu, 15 May 2025 21:11:55 GMT, Phil Race <prr at openjdk.org> wrote:

> Most of it wasn't really directed at you .. more at Kevin :-)

Those are good questions as to how we might need to evolve this if and when JavaFX adds desktop-like APIs. We might, indeed, want some sort of "forward these events to the other toolkit if and only if they aren't for you" on both ends.

> The main question I had for you was about did it ever really work and I guess you aren't sure.

Based on my testing of this, I very much doubt anything in macOS has changed in a way to affect this. I strongly suspect that it may have (accidentally) worked prior to JDK 22 / JavaFX 22 when we fixed the bug where AWT was taking over the NSApplicationDelegate even if it was embedded in JavaFX. See [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) and [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669).

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2885286756

From srl at openjdk.org  Fri May 16 03:36:59 2025
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 16 May 2025 03:36:59 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <hNAYw_Bo_VoU_zXO-qdXi7i-UadsoaTFFKFgqXkwvSc=.28d4f342-e7f2-4953-818d-0a15ce63a020@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

It?s still there if you click through.
https://keyman.com/go/package/download/isis_devanagari?version=2.1.1&tier=stable

El El jue, 15 may 2025 a la(s) 6:05?p.m., Andy Goryachev <
***@***.***> escribi?:

> *andy-goryachev-oracle* left a comment (openjdk/jfx#1805)
> <https://github.com/openjdk/jfx/pull/1805#issuecomment-2885238974>
>
> @srl295 <https://github.com/srl295>
> ISIS Devanagari is no longer available:
> https://keyman.com/keyboards/isis_devanagari
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/1805#issuecomment-2885238974>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAGQZMZUMO6WLDDCFA6TXBT26UMT3AVCNFSM6AAAAAB5DW52UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBVGIZTQOJXGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2885545654

From lkostyra at openjdk.org  Fri May 16 06:13:57 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 16 May 2025 06:13:57 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level
In-Reply-To: <RJJLvgkAuDqsLEy_OXIMSsFSsHO4i7VHTsC6nnWqZrs=.3edf08ac-d8f7-4eb7-84db-a2bf4684a69b@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <wPlStIhdS9KUtTcJNpk4YpwaIuqxFXl-SntxYHpAKss=.1d6e92ff-c0e9-4dee-b26e-2a047a3b76cb@github.com>
 <RJJLvgkAuDqsLEy_OXIMSsFSsHO4i7VHTsC6nnWqZrs=.3edf08ac-d8f7-4eb7-84db-a2bf4684a69b@github.com>
Message-ID: <emqUsMoGROMms6uCIzUQoAJnolJMts7ZzZ32bVZ6zDA=.24b66aca-2b32-4b02-9847-f5162dd8e62f@github.com>

On Thu, 15 May 2025 20:18:04 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 166:
>> 
>>> 164:         return true;
>>> 165:     }
>>> 166: 
>> 
>> 1. Is looking for a slash going to be compatible on all platforms?  Where is the path string coming from?
>> 2. Catching `NumberFormatException` to "check" if something is a number is bad form
>> 3. It will allow `@0x` and `@-1x` etc...
>> 4. Consider using a regular expression, it is much more concise and intended for this kind of matching
>> 
>> Here's a regular expression for this:
>> 
>>     Pattern SCALED_PATTERN = Pattern.compile(".*@[1-9][0-9]?x(\.[^\.]+)?");
>>     
>> The above will match any path that ends with `@` followed by a number from 1 to 99, followed by an `x`, optionally followed by an extension that does not contain a dot.  No need to check for slashes.
>
> If you want you can even return the scale with a slightly altered pattern:
> 
>      private static final Pattern SCALED_PATTERN = Pattern.compile(".*@([1-9][0-9]?)x(?:\.[^\.]+)?");
>      
> Then do:
> 
>      Matcher matcher = SCALED_PATTERN.matcher(path);
>      
>      if (matcher.matches()) {
>           return Integer.parseInt(matcher.group(1));  // can't throw NumberFormatException, number is validated by pattern
>      }
>      
>      return 0;  // there was no scale

>Is looking for a slash going to be compatible on all platforms? Where is the path string coming from?

My assumption was that other parts of ImageTools use this assumption so here it would be okay as well. `getScaledImageName` right above this method assumes so (although there it might not matter as much).

Regex might be a better fit for this, I agree.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1809#discussion_r2092390883

From lkostyra at openjdk.org  Fri May 16 07:03:38 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 16 May 2025 07:03:38 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v2]
In-Reply-To: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
Message-ID: <EFiEr-5ygKl-JMqzT7NF3OmqHeny0sgf_1T0xqv7FsM=.dbe0afd5-a556-4058-ad52-6c41f57d59ec@github.com>

> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
> 
> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
> 
> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

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

  Replace hasScaledName logic with regex

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1809/files
  - new: https://git.openjdk.org/jfx/pull/1809/files/44c41763..64e8c2e0

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

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

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

From mstrauss at openjdk.org  Fri May 16 10:15:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 10:15:45 GMT
Subject: RFR: 8357067: Platform preference change can emit multiple
 notifications [v3]
In-Reply-To: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
Message-ID: <YLqCeHChoPRd0ZR40UACSNWdfycbjxQoeRtMFLL5PBI=.a826d6cb-5b63-4f19-9f90-e206c1beda4c@github.com>

> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
> 
> 
> changed:
> 	Windows.UIColor.Accent=0x0078d4ff
> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
> 	Windows.UIColor.AccentLight1=0x0091f8ff
> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
> 	Windows.UIColor.Foreground=0x000000ff
> 	Windows.UIColor.AccentDark1=0x0067c0ff
> 	Windows.UIColor.Background=0xffffffff
> 	Windows.UIColor.AccentLight3=0x99ebffff
> 	Windows.UIColor.AccentLight2=0x4cc2ffff
> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
> 	Windows.UIColor.AccentDark2=0x003e92ff
> 	Windows.UIColor.AccentDark3=0x001a68ff
> 
> changed:
> 	-Windows.SPI.HighContrastColorScheme
> 	Windows.SPI.HighContrast=false
> 
> changed:
> 	Windows.UIColor.Foreground=0xffffffff
> 	Windows.UIColor.Background=0x000000ff
> 
> 
> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
> 
> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
> 
> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.

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

  use try-finally

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1810/files
  - new: https://git.openjdk.org/jfx/pull/1810/files/8fce572c..78139e5c

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

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1810.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1810/head:pull/1810

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

From johan.vos at gluonhq.com  Fri May 16 12:14:28 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 16 May 2025 14:14:28 +0200
Subject: Headless Platform module?
Message-ID: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>

Hi,

The Headless Glass Platform has been in the jfx sandbox repository [1] for
some time now, and we have provided a number of builds allowing users to
test the headless platform. The reactions were very positive. It's mainly
being used in 2 areas: testing is obviously a major usecase, especially
remote testing and testing on systems where you don't want a UI to popup
while developing; and applications where desktop functionality is used
(e.g. printing, snapshots,...) without a UI window being shown.

I got a number of requests from developers who want to see this part of a
non-sandbox build of OpenJFX.
Hence, I want to start the work on adding the headless functionality in the
OpenJFX main repository. If you look at the diff between the current head
of the headless branch [1] and the master branch, you'll notice it almost
exclusively touches a new package: com.sun.glass.ui.headless.
There are some minor changes in quantum and gtk, but those can be handled
separately.

Before starting the work on a JEP and a PR, I'd like to discuss the
following: do we want the headless platform to be part of an existing
module (javafx.graphics), or do we want it to be part of a new module?
Currently, all glass platforms are part of the same module
(javafx.graphics), and different SDKs contain different implementations --
with the Java top-level API being the same in all modules.

Apart from Monocle, there is a (non-official) 1-1 match between OS platform
and glass platform (e.g. linux using GTK, MacOS using mac, iOS using
ios,...). Therefore, the jmods, which are OS-specific, can be (and are)
organized in a way that they only contain the code that is relevant to the
target OS. It would be bad if the javafx.graphics jmod for linux contained
the windows-specific glass platform.
Monocle violates this rule, because it is platform-independent (at its own
top-level, that is, because inside Monocle are a bunch of platform-specific
components). Our "official" builds do not include Monocle, but we also
offer builds with monocle, and it is pretty confusing. There is some logic
in the current build.gradle that either includes or excludes monocle from
the modules.

I want to avoid this confusion with the Headless Platform.
It is clear that a javafx.graphics module for MacOS should not contain code
for Windows, but should it contain code for Headless? I would expect the
answer to be "no". But then, how can developers use the Headless Platform?
The bad scenario is the one that currently is used with monocle, where the
answer is: "It depends". If you download a "monocle SDK", then the
javafx.graphcis jmod contains monocle, and your SDK can use monocle, hence
setting glass.platform=Monocle will work. But with a regular build, the
same will not work.

Therefore, I believe it is worth considering the Headless Platform to move
into its own module. If developers want to leverage the Headless Platform,
they need to add the module. This requires work in the javafx.graphics
module, as the headless code requires access to con.sun.glass.ui code, but
I don't see any major issues here -- although I don't want to underestimate
the work needed to securely add "glass providers" inside javafx.graphics.
The latter might open the road to external glass implementations being
added at runtime in specific configurations.

A drawback I see for this approach is that the Headless Platform is then
treated differently from the other (existing) platforms. The GTK, mac, win,
android, ios platforms are all part of a single module, where the Headless
Platform would be in its own module. As explained before, there is a very
good reason for this (the 1-1 match between those platforms and the target
system OS), so I don't see that as an ugly thing.

Before going in more detail, I'd like to hear opinions about this proposal
to add a new module for the Headless Platform.

- Johan

[1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
[2] https://gluonhq.com/products/javafx/ , select [Headless] in JavaFX
version
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250516/27987f1a/attachment.htm>

From gpattnaik at openjdk.org  Fri May 16 12:58:36 2025
From: gpattnaik at openjdk.org (Gopal Pattnaik)
Date: Fri, 16 May 2025 12:58:36 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
Message-ID: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>

On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview

Solution:
Added a version string in the user agent similar to Safari.

Verification:
The test program attached to the JBS passes with this change.

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

Commit messages:
 - Microsoft Login-Code Review addressed
 - Fix for Microsoft Login

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

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

From gpattnaik at openjdk.org  Fri May 16 12:58:37 2025
From: gpattnaik at openjdk.org (Gopal Pattnaik)
Date: Fri, 16 May 2025 12:58:37 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <uRcSKcsmWQnfh04CMmrAod4rF0utxsUKtTt_brMVP4U=.a103ddc3-0ed7-460e-bc12-1e20a3f40343@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
 <uRcSKcsmWQnfh04CMmrAod4rF0utxsUKtTt_brMVP4U=.a103ddc3-0ed7-460e-bc12-1e20a3f40343@github.com>
Message-ID: <oP-ZD2FrAU5qzDy3MV_dmxVNiallyxw3gBpHnk0sLww=.cf06ea12-eba7-41f9-a146-a49a860376a5@github.com>

On Thu, 15 May 2025 12:36:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This looks reasonable. Please update the description with what testing you have done on various websites.
> 
> I left one clarifying suggestion inline.

I tested some social media and bank urls and the page was loading as expected.

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

PR Comment: https://git.openjdk.org/jfx/pull/1808#issuecomment-2885798432

From kcr at openjdk.org  Fri May 16 12:58:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 May 2025 12:58:37 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <uRcSKcsmWQnfh04CMmrAod4rF0utxsUKtTt_brMVP4U=.a103ddc3-0ed7-460e-bc12-1e20a3f40343@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

This looks reasonable. Please update the description with what testing you have done on various websites.

I left one clarifying suggestion inline.

Reviewers: @jaybhaskar @kevinrushforth

Reviewers: @jaybhaskar @kevinrushforth

build.gradle line 623:

> 621: defineProperty("PROMOTED_BUILD_NUMBER", "0")
> 622: defineProperty("MILESTONE_FCS", "false")
> 623: defineProperty("WEBVIEW_VERSION", "18.4")

Can you separate this from the previous 4 "Husdon" definitions by a blank line and also add a comment?

build.gradle line 4023:

> 4021:                         targetCpuBitDepthSwitch = "--32-bit"
> 4022:                     }
> 4023:                     cmakeArgs += " -DWEBVIEW_RELEASE_VERSION=${WEBVIEW_VERSION}"

Since this is a browser version, as noted in the PR Description, I recommend changing this variable name here and in the below files to `WEBVIEW_BROWSER_VERSION`.

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

PR Review: https://git.openjdk.org/jfx/pull/1808#pullrequestreview-2843526871
PR Comment: https://git.openjdk.org/jfx/pull/1808#issuecomment-2883667277
PR Comment: https://git.openjdk.org/jfx/pull/1808#issuecomment-2886618250
PR Review Comment: https://git.openjdk.org/jfx/pull/1808#discussion_r2091112101
PR Review Comment: https://git.openjdk.org/jfx/pull/1808#discussion_r2091070643

From mstrauss at openjdk.org  Fri May 16 14:43:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 14:43:07 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes application
Message-ID: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>

When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.

The following program demonstrates the defect:


public class FailingAnimationTimer extends Application {
    @Override
    public void start(Stage stage) throws Exception {
        var button = new Button("start timer");
        button.setOnAction(_ -> {
            var timer = new AnimationTimer() {
                @Override
                public void handle(long l) {
                    throw new RuntimeException("foo");
                }
            };

            timer.start();
        });

        var root = new HBox();
        root.getChildren().add(new TextField("test"));
        root.getChildren().add(button);
        stage.setScene(new Scene(root));
        stage.show();
    }
}


The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.

In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:

`WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`

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

Commit messages:
 - fix
 - failing test

Changes: https://git.openjdk.org/jfx/pull/1811/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1811&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357157
  Stats: 224 lines in 2 files changed: 200 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1811.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1811/head:pull/1811

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

From jhendrikx at openjdk.org  Fri May 16 14:51:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 16 May 2025 14:51:58 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v2]
In-Reply-To: <EFiEr-5ygKl-JMqzT7NF3OmqHeny0sgf_1T0xqv7FsM=.dbe0afd5-a556-4058-ad52-6c41f57d59ec@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EFiEr-5ygKl-JMqzT7NF3OmqHeny0sgf_1T0xqv7FsM=.dbe0afd5-a556-4058-ad52-6c41f57d59ec@github.com>
Message-ID: <6OF_GYnIY7XPzVG7BkeNMpkCre3I4dkMgFhapNTrLEE=.abe07807-65a9-4829-befa-98f6eeff4285@github.com>

On Fri, 16 May 2025 07:03:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace hasScaledName logic with regex

Looks good; you could add tests to check if `@0x` and `@-1x` are now indeed not recognized as scaled names.

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1809#pullrequestreview-2846876624

From srl at openjdk.org  Fri May 16 15:25:57 2025
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 16 May 2025 15:25:57 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <EewELyk474Z6EE8rVYm2AMs2__TRqWK0IpWB0OI1gIY=.1ad99e88-7a48-45df-b0a6-80cd9b6ace06@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

Looks reasonable to me

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

Marked as reviewed by srl (no project role).

PR Review: https://git.openjdk.org/jfx/pull/1805#pullrequestreview-2846964516

From angorya at openjdk.org  Fri May 16 17:43:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 17:43:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <R2heGGJiBFef91Zxxx5IbiFb_8nxDxFyChUzVFU2zHM=.7abe083c-2999-47c4-8a17-2be31499d11f@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

OK, here is the test result with keyman ISIS Devanagari looks like:

with the fix -

Typing "j"  displays ?
Typing "ji" displays ???
Typing "naam" displays ????
Typing "kala" displays ????

without the fix -

Typing "j"  displays j
Typing "ji" displays j??
Typing "naam" displays naam
Typing "kala" displays kala

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2887327613

From angorya at openjdk.org  Fri May 16 17:55:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 17:55:55 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application
In-Reply-To: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
Message-ID: <XEpAXxvjKpRJSjMSWFshodHqdVFGlcvThDyDNXzclms=.2d9bc97e-b964-4657-a9d0-b5e512ff2f6c@github.com>

On Fri, 16 May 2025 14:38:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
> 
> The following program demonstrates the defect:
> 
> 
> public class FailingAnimationTimer extends Application {
>     @Override
>     public void start(Stage stage) throws Exception {
>         var button = new Button("start timer");
>         button.setOnAction(_ -> {
>             var timer = new AnimationTimer() {
>                 @Override
>                 public void handle(long l) {
>                     throw new RuntimeException("foo");
>                 }
>             };
> 
>             timer.start();
>         });
> 
>         var root = new HBox();
>         root.getChildren().add(new TextField("test"));
>         root.getChildren().add(button);
>         stage.setScene(new Scene(root));
>         stage.show();
>     }
> }
> 
> 
> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
> 
> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
> 
> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 66:

> 64:     private final int PULSE_DURATION_TICKS = getPulseDuration((int)TickCalculation.fromMillis(1000));
> 65: 
> 66:     private static final String FAILING_TIMER_THRESHOLD_PROP = "com.sun.scenario.animation.failingTimerThreshold";

maybe a comment describing what this property does would be helpful for the digital paleontologist of the future

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 331:

> 329:         }
> 330: 
> 331:         receiversLocked = false;

if L327 throws an exception, `receiversLocked` will not get cleared.

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 347:

> 345:         }
> 346: 
> 347:         animationTimersLocked = false;

same here

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093467739
PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093466067
PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093466315

From mstrauss at openjdk.org  Fri May 16 18:00:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 18:00:57 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v2]
In-Reply-To: <EFiEr-5ygKl-JMqzT7NF3OmqHeny0sgf_1T0xqv7FsM=.dbe0afd5-a556-4058-ad52-6c41f57d59ec@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EFiEr-5ygKl-JMqzT7NF3OmqHeny0sgf_1T0xqv7FsM=.dbe0afd5-a556-4058-ad52-6c41f57d59ec@github.com>
Message-ID: <CBvf1xDO2WK_Y8bAhWhzr61Abz-vNI2wWJB6WssuXz4=.bb84d688-10a9-460e-9d9b-7122e318e35e@github.com>

On Fri, 16 May 2025 07:03:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace hasScaledName logic with regex

modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 55:

> 53:      * Regex pattern for hasScaledName
> 54:      */
> 55:     private static final Pattern SCALED_FILE_PATTERN = Pattern.compile(".*@[1-9][0-9]?x(\\.[^\\.]+)?");

You can use a non-capturing group instead of a capturing group if you don't intend to retrieve its value:
Suggestion:

    private static final Pattern SCALED_FILE_PATTERN = Pattern.compile(".*@[1-9][0-9]?x(?:\.[^\.]+)?");

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1809#discussion_r2093474688

From mstrauss at openjdk.org  Fri May 16 18:12:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 18:12:35 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
Message-ID: <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>

> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
> 
> The following program demonstrates the defect:
> 
> 
> public class FailingAnimationTimer extends Application {
>     @Override
>     public void start(Stage stage) throws Exception {
>         var button = new Button("start timer");
>         button.setOnAction(_ -> {
>             var timer = new AnimationTimer() {
>                 @Override
>                 public void handle(long l) {
>                     throw new RuntimeException("foo");
>                 }
>             };
> 
>             timer.start();
>         });
> 
>         var root = new HBox();
>         root.getChildren().add(new TextField("test"));
>         root.getChildren().add(button);
>         stage.setScene(new Scene(root));
>         stage.show();
>     }
> }
> 
> 
> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
> 
> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
> 
> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1811/files
  - new: https://git.openjdk.org/jfx/pull/1811/files/4a17479c..918b0606

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

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

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

From mstrauss at openjdk.org  Fri May 16 18:12:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 18:12:35 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <XEpAXxvjKpRJSjMSWFshodHqdVFGlcvThDyDNXzclms=.2d9bc97e-b964-4657-a9d0-b5e512ff2f6c@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XEpAXxvjKpRJSjMSWFshodHqdVFGlcvThDyDNXzclms=.2d9bc97e-b964-4657-a9d0-b5e512ff2f6c@github.com>
Message-ID: <Dy66ak63pmgeL-xlAaCvZQr9-NSOJGtvdoyR5y1lzcM=.ec84e6e3-f3ed-4e4c-8e91-4f776b341edd@github.com>

On Fri, 16 May 2025 17:51:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 331:
> 
>> 329:         }
>> 330: 
>> 331:         receiversLocked = false;
> 
> if L327 throws an exception, `receiversLocked` will not get cleared.

I've changed the `handleException` method so it will not throw.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093488460

From angorya at openjdk.org  Fri May 16 18:29:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 18:29:55 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
Message-ID: <yyApFwJ_duWAhfQZEtraacIBzZKG3ZReWT7pwbs3kG4=.ca70bc37-d45e-4574-a581-3e206313c887@github.com>

On Fri, 16 May 2025 18:12:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 380:

> 378:                     Thread thread = Thread.currentThread();
> 379:                     thread.getUncaughtExceptionHandler().uncaughtException(thread, e);
> 380:                 } catch (Throwable ignored) {

any reason not to wrap the whole method in `try`/`catch`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093508251

From angorya at openjdk.org  Fri May 16 18:37:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 18:37:59 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
Message-ID: <HJuUKI7F6TsXGQPPWsUr1A8CmYQhIciPVp982CoUvHk=.9c10c842-79f7-4100-bd82-d5283d10c4af@github.com>

On Fri, 16 May 2025 18:12:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 90:

> 88: 
> 89:     @SuppressWarnings("unchecked")
> 90:     private ReceiverRecord<PulseReceiver>[] receivers = new ReceiverRecord[2];

weird that there is no way to do it cleanly without `@SuppressWarnings("unchecked")`

BTW, Eclipse shows 5,608 hits if I enable "unchecked generic type operation" warning.  Pretty useless, if you ask me.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093517030

From mstrauss at openjdk.org  Fri May 16 18:40:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 18:40:54 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <yyApFwJ_duWAhfQZEtraacIBzZKG3ZReWT7pwbs3kG4=.ca70bc37-d45e-4574-a581-3e206313c887@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <yyApFwJ_duWAhfQZEtraacIBzZKG3ZReWT7pwbs3kG4=.ca70bc37-d45e-4574-a581-3e206313c887@github.com>
Message-ID: <ZLZ9aTDLOLrTefeTpFg36ODOErrsvvxwq2bK9IYXKMg=.5bc7037d-dd92-48c4-8f4f-977304a5fb93@github.com>

On Fri, 16 May 2025 18:27:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 380:
> 
>> 378:                     Thread thread = Thread.currentThread();
>> 379:                     thread.getUncaughtExceptionHandler().uncaughtException(thread, e);
>> 380:                 } catch (Throwable ignored) {
> 
> any reason not to wrap the whole method in `try`/`catch`?

There isn't anything else in there that could throw, except for the logger itself. I don't think it makes sense to try to account for failing loggers, as basically everything will break if that's the case.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093520616

From angorya at openjdk.org  Fri May 16 18:49:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 18:49:55 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
Message-ID: <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>

On Fri, 16 May 2025 18:12:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 352:

> 350:     }
> 351: 
> 352:     private static abstract class ReceiverRecord<T> {

All this does look complicated, just to limit the number of messages in the log (a noble cause).

What if we just print the first message and ignore the rest?  It might be relatively unlikely that two different failures appeared at the same time, each with its own root cause?

If we just show the first one, we'll remove all this complexity and the system property, and possibly get back to the simpler original code?

What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093530134

From mstrauss at openjdk.org  Fri May 16 18:55:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 18:55:54 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
Message-ID: <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>

On Fri, 16 May 2025 18:47:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 352:
> 
>> 350:     }
>> 351: 
>> 352:     private static abstract class ReceiverRecord<T> {
> 
> All this does look complicated, just to limit the number of messages in the log (a noble cause).
> 
> What if we just print the first message and ignore the rest?  It might be relatively unlikely that two different failures appeared at the same time, each with its own root cause?
> 
> If we just show the first one, we'll remove all this complexity and the system property, and possibly get back to the simpler original code?
> 
> What do you think?

We're throwing away all exceptions after a certain point (either after the first, or some number of exceptions after that). A potential use case would be debugging a large application that for some reason throws lots of different exceptions from timers. There can't be many applications that do this, because right now that would most likely just freeze the application. I'm okay either way (logging the first exception, or logging the first 100 exceptions with a user-configurable threshold).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093536927

From mstrauss at openjdk.org  Fri May 16 19:05:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 19:05:57 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
Message-ID: <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>

On Fri, 16 May 2025 18:52:57 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java line 352:
>> 
>>> 350:     }
>>> 351: 
>>> 352:     private static abstract class ReceiverRecord<T> {
>> 
>> All this does look complicated, just to limit the number of messages in the log (a noble cause).
>> 
>> What if we just print the first message and ignore the rest?  It might be relatively unlikely that two different failures appeared at the same time, each with its own root cause?
>> 
>> If we just show the first one, we'll remove all this complexity and the system property, and possibly get back to the simpler original code?
>> 
>> What do you think?
>
> We're throwing away all exceptions after a certain point (either after the first, or some number of exceptions after that). A potential use case would be debugging a large application that for some reason throws lots of different exceptions from timers. There can't be many applications that do this, because right now that would most likely just freeze the application. I'm okay either way (logging the first exception, or logging the first 100 exceptions with a user-configurable threshold).

We could also just keep it with a fixed threshold, but remove the system property.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093548803

From angorya at openjdk.org  Fri May 16 19:05:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 19:05:57 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
Message-ID: <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>

On Fri, 16 May 2025 19:03:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> We're throwing away all exceptions after a certain point (either after the first, or some number of exceptions after that). A potential use case would be debugging a large application that for some reason throws lots of different exceptions from timers. There can't be many applications that do this, because right now that would most likely just freeze the application. I'm okay either way (logging the first exception, or logging the first 100 exceptions with a user-configurable threshold).
>
> We could also just keep it with a fixed threshold, but remove the system property.

It just seems unnecessary to add all this complexity.  The first exception is all we need, really - we can skip the 2nd, 3rd, ...  This might rule out the property.

It might be unlikely that two or more completely unrelated failures would happen in the field in a well-tested application [citation needed], I think there is a little value in trying to add this complex logic per timer.  A static boolean might suffice.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093548949

From mstrauss at openjdk.org  Fri May 16 19:20:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 16 May 2025 19:20:56 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
 <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
Message-ID: <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>

On Fri, 16 May 2025 19:03:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> We could also just keep it with a fixed threshold, but remove the system property.
>
> It just seems unnecessary to add all this complexity.  The first exception is all we need, really - we can skip the 2nd, 3rd, ...  This might rule out the property.
> 
> It might be unlikely that two or more completely unrelated failures would happen in the field in a well-tested application [citation needed], I think there is a little value in trying to add this complex logic per timer.  A static boolean might suffice.

On the other hand, AnimationTimer is a public API that allows for arbitrary code execution, which always has the potential to fail for any number of reasons (think of calling an unstable API from the timer callback). We can?t rule that out entirely. This is only a fallback in any case, as a well-tested application shouldn?t throw exceptions from timer callbacks in the first place.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2093564875

From kcr at openjdk.org  Fri May 16 21:05:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 May 2025 21:05:00 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <gG61dKZuWFsneshL_WnWs7qkpBcBePe5sziYZq0i0RQ=.6c282989-98b5-466f-8349-a6e3eabb53e0@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

The changes look good. A local build works. I fired off a test build on our CI server and will approve once it completes with no errors.

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

PR Review: https://git.openjdk.org/jfx/pull/1803#pullrequestreview-2847619286

From mfox at openjdk.org  Fri May 16 22:25:20 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 May 2025 22:25:20 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

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

  Second try at making Keyman work to some extent

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1805/files
  - new: https://git.openjdk.org/jfx/pull/1805/files/86410203..c8f42a45

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

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

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

From mfox at openjdk.org  Fri May 16 22:25:20 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 May 2025 22:25:20 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
Message-ID: <MoxxuO-75GqubZSrUSh7_eLUsuHzruCZO-vS179gdPU=.91596339-3f55-4f77-91ce-042135693f93@github.com>

On Wed, 14 May 2025 15:31:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
> 
> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.

A second shot at getting the Keyman input method working. In this version we detect that Keyman is active at the very beginning of key down handling. If Keyman is active we drop any key event that doesn?t lead to a call to one of the NSTextInputClient methods. Character-generating keys are caught inside `insertText:replacementRange:`. All other keys (like Home, Backspace, Delete, function keys, etc.) are caught in `doCommandBySelector:`. Note: AWT uses a different heuristic; it captures keys like Home in `performKeyEquivalent:`.

Under the hood Keyman is using some Roman layout (for me it?s US English) and all keyboard shortcuts will be based on that layout and not the Keyman layout. So if you test with Dvorak shortcuts like Cmd+X require you to hit X in the US English (QWERTY) location, not the Dvorak one. This is a general problem with Keyman that affects all applications.

A keystroke that generate more than one UTF-16 code unit will be processed as a JavaFX InputMethodEvent rather than a KeyEvent. This is old logic that?s been in JavaFX for a long time that I didn?t want to re-visit. You?ll see this with the Himyarit Musnad layout.

I tried to isolate the Keyman logic as much as possible. I?ve done some testing with Himyarit Musnad, Hebrew, and ISIS-Devanagari. It won?t work the newer Guatami Devanagari since it keeps sending backspaces to erase previous characters. That layout doesn?t seem to work well anywhere.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2887775192

From srl at openjdk.org  Fri May 16 22:44:56 2025
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 16 May 2025 22:44:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
In-Reply-To: <MoxxuO-75GqubZSrUSh7_eLUsuHzruCZO-vS179gdPU=.91596339-3f55-4f77-91ce-042135693f93@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <MoxxuO-75GqubZSrUSh7_eLUsuHzruCZO-vS179gdPU=.91596339-3f55-4f77-91ce-042135693f93@github.com>
Message-ID: <zd6FbGXJUQGrsiAdQ2f3Y0S15Xz4QXHNOKZVKu4CQ6o=.6f5df26b-9a49-487c-a0c7-8e75465032e7@github.com>

On Fri, 16 May 2025 22:21:52 GMT, Martin Fox <mfox at openjdk.org> wrote:

> keeps sending backspaces to erase previous characters

I do know that keyboards in general need to be able to interact with the existing context, that is, to convert h + i into ? erasing the "h". I'm not sure of the correct mechanism here but just wanted to note that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2887799144

From angorya at openjdk.org  Fri May 16 23:04:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 23:04:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
Message-ID: <X-BpBw1wlS59SLjSaJYk7NlATK3MsKEvzwUJblYZ0kU=.442f430b-8931-42f6-b381-5263bb4f03d4@github.com>

On Fri, 16 May 2025 22:25:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
>> 
>> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second try at making Keyman work to some extent

As far as I can tell, this version works as expected.

I found one irregularity with the ISIS Devanagari keyboard: unmapped 'w' produces w symbol, unmapped punctuation keys produce corresponding symbols, but unmapped 'x' produces no input.  This could be the keyman problem though.

It is weird that we have to add third-party specific code to JavaFX as a workaround - why doesn't macOS provide a general purpose API for this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2887816404

From angorya at openjdk.org  Fri May 16 23:15:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 May 2025 23:15:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
Message-ID: <73tJ0_tQnPfglmXCi_MleQO2I6IsCzWIsNSSyRSP1rk=.05e3d1d6-5b1c-4828-8947-7b9d0090e932@github.com>

On Fri, 16 May 2025 22:25:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
>> 
>> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second try at making Keyman work to some extent

modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 806:

> 804:     // but a text input client should not. So we ignore this which avoids an
> 805:     // annoying beep.
> 806:     if (keymanActive) {

I noticed the latest code does not beep.  Were the beeps produced earlier expected for unmapped keys?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1805#discussion_r2093763002

From kevin.rushforth at oracle.com  Fri May 16 23:25:14 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 16 May 2025 16:25:14 -0700
Subject: Headless Platform module?
In-Reply-To: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>
References: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>
Message-ID: <cdea6487-6cd8-4fb8-9d38-521ba5994c9e@oracle.com>

Interesting questions. There are two high level questions here (I 
think). First, should the Monocle headless platform be part of the 
javafx.graphics module or should it be a separate module? Second, should 
the headless "platform" be considered a completely different OS platform 
or, since it is largely platform-independent, should the headless 
platform be built and bundled with each OS. The two questions are 
somewhat related.

I haven't looked at the implementation of the headless platform, so this 
is a somewhat less informed opinion than it would be once I do.

As long as it is fairly small and doesn't have any public API surface 
(meaning that the only way to use it is a system property that then 
loads the Monocle glass backend along with another system property that 
selects the headless Monocle platform), it would seem easiest to leave 
it in javafx.graphics. This would mean we would start shipping the 
Monocle classes that we currently exclude as well as the new headless 
package. The second one depends on whether or not there is any native 
code associated with the headless glass platform. If not, then the 
easiest thing to do would be to always include it on all OS platforms.

There might be some advantages to putting it in its own module, but 
without also moving all of Monocle to a different module, this sounds 
like a lot of work and also would raise some issues that would have to 
be solved. Would we need to define an SPI? Formalize the Monocle back 
end interfaces? Hmm.

Anyway, this is just food for thought at this point.

-- Kevin


On 5/16/2025 5:14 AM, Johan Vos wrote:
> Hi,
>
> The Headless Glass Platform has been in the jfx sandbox repository [1] 
> for some time now, and we have provided a number of builds allowing 
> users to test the headless platform. The reactions were very positive. 
> It's mainly being used in 2 areas: testing is obviously a major 
> usecase, especially remote testing and testing on systems where you 
> don't want a UI to popup while developing; and applications where 
> desktop functionality is used (e.g. printing, snapshots,...) without a 
> UI window being shown.
>
> I got a number of requests from developers who want to see this part 
> of a non-sandbox build of OpenJFX.
> Hence, I want to start the work on adding the headless functionality 
> in the OpenJFX main repository. If you look at the diff between the 
> current head of the headless branch [1] and the master branch, you'll 
> notice it almost exclusively touches a new package: 
> com.sun.glass.ui.headless.
> There are some minor changes in quantum and gtk, but those can be 
> handled separately.
>
> Before starting the work on a JEP?and a PR, I'd like to discuss the 
> following: do we want the headless platform to be part of an existing 
> module (javafx.graphics), or do we want it to be part of a new module?
> Currently, all glass platforms are part of the same module 
> (javafx.graphics), and different SDKs contain different 
> implementations -- with the Java top-level API being the same in all 
> modules.
>
> Apart from Monocle, there is a (non-official) 1-1 match between OS 
> platform and glass platform (e.g. linux using GTK, MacOS using mac, 
> iOS using ios,...). Therefore, the jmods, which are OS-specific, can 
> be (and are) organized in a way that they only contain the code that 
> is relevant to the target OS. It would be bad if the javafx.graphics 
> jmod for linux contained the windows-specific glass platform.
> Monocle violates this rule, because it is platform-independent (at its 
> own top-level, that is, because inside Monocle are a bunch of 
> platform-specific components). Our "official" builds do not include 
> Monocle, but we also offer builds with monocle, and it is pretty 
> confusing. There is some logic in the current build.gradle that either 
> includes or excludes monocle from the modules.
>
> I want to avoid this confusion with the Headless Platform.
> It is clear that a javafx.graphics module for MacOS should not contain 
> code for Windows, but should it contain code for Headless? I would 
> expect the answer to be "no". But then, how can developers use the 
> Headless Platform? The bad scenario is the one that currently is used 
> with monocle, where the answer is: "It depends". If you download a 
> "monocle SDK", then the javafx.graphcis jmod?contains monocle, and 
> your SDK can use monocle, hence setting glass.platform=Monocle will 
> work. But with a regular build, the same will not work.
>
> Therefore, I believe it is worth considering the Headless Platform to 
> move into its own module. If developers want to leverage the Headless 
> Platform, they need to add the module. This requires work in the 
> javafx.graphics module, as the headless code requires access to 
> con.sun.glass.ui code, but I don't see any major issues here -- 
> although I don't want to underestimate the work needed to securely add 
> "glass providers" inside javafx.graphics. The latter might open the 
> road to external glass implementations being added at runtime in 
> specific configurations.
>
> A drawback I see for this approach is that the Headless Platform is 
> then treated differently from the other (existing) platforms. The GTK, 
> mac, win, android, ios platforms are all part of a single module, 
> where the Headless Platform would be in its own module. As explained 
> before, there is a very good reason for this (the 1-1 match between 
> those platforms and the target system OS), so I don't see that as an 
> ugly thing.
>
> Before going in more detail, I'd like to hear opinions about this 
> proposal to add a new module for the Headless Platform.
>
> - Johan
>
> [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
> [2] https://gluonhq.com/products/javafx/ , select [Headless] in JavaFX 
> version


From kcr at openjdk.org  Fri May 16 23:28:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 May 2025 23:28:55 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <vslQS6mLpCXGg4CGmT007VHWWWrmBDuB7p-fH7BzUKA=.e8e4dca3-ec60-4514-87ca-93522c72bc70@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

All good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1803#pullrequestreview-2847758410

From mfox at openjdk.org  Sat May 17 00:15:55 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 17 May 2025 00:15:55 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <73tJ0_tQnPfglmXCi_MleQO2I6IsCzWIsNSSyRSP1rk=.05e3d1d6-5b1c-4828-8947-7b9d0090e932@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
 <73tJ0_tQnPfglmXCi_MleQO2I6IsCzWIsNSSyRSP1rk=.05e3d1d6-5b1c-4828-8947-7b9d0090e932@github.com>
Message-ID: <gCM5yc-1G8tFojP2x5sZydhOjPKuLnkvuKyPw8OXSek=.561e6d09-a832-4a2d-815d-a2405296a722@github.com>

On Fri, 16 May 2025 23:13:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Second try at making Keyman work to some extent
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 806:
> 
>> 804:     // but a text input client should not. So we ignore this which avoids an
>> 805:     // annoying beep.
>> 806:     if (keymanActive) {
> 
> I noticed the latest code does not beep.  Were the beeps produced earlier expected for unmapped keys?

I'm not sure where the beeps are coming from. I still hear a beep when I press N on the Himyarit Musnad layout but I don't hear a beep when I press X on the ISIS-Devanagari layout. Both are unused keys but one produces a beep and the other doesn't.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1805#discussion_r2093787087

From mfox at openjdk.org  Sat May 17 00:30:56 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 17 May 2025 00:30:56 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <X-BpBw1wlS59SLjSaJYk7NlATK3MsKEvzwUJblYZ0kU=.442f430b-8931-42f6-b381-5263bb4f03d4@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
 <X-BpBw1wlS59SLjSaJYk7NlATK3MsKEvzwUJblYZ0kU=.442f430b-8931-42f6-b381-5263bb4f03d4@github.com>
Message-ID: <_EGP6EIPwKlQ1gA_MIek4UVXYgehA5IfOzJ4lRdUIPI=.aa5e735b-37d8-4b81-8d10-4986c59b5fc2@github.com>

On Fri, 16 May 2025 23:02:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> It is weird that we have to add third-party specific code to JavaFX as a workaround - why doesn't macOS provide a general purpose API for this?

Normally an input method is designed for a specific language and is bundled with a collection of keyboard layouts. The input method is an active blob of code but the keyboard layouts are basically big passive tables mapping hardware key positions to characters. It appears that Keyman is trying to use one input method that works with all of its layouts. It's not producing the corresponding data tables; the OS just sees the same Roman table when it generates events. We're basically working around that mis-match.

To really do this right Keyman would either have to create new layout tables on-the-fly (assuming they can, I've never tried it) or use a low-level event tap to re-write the keyboard events (assuming they can, I've never tried it). I suspect the API's are available but are probably a devil to get right.

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2887887550

From peterhull90 at gmail.com  Sat May 17 09:26:58 2025
From: peterhull90 at gmail.com (Peter Hull)
Date: Sat, 17 May 2025 10:26:58 +0100
Subject: Error building from source on Mac
Message-ID: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>

If I checkout from git and attempt to build with `sh gradlew` I get this error:

/Projects/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m:122:14:
error: comparison of different enumeration types ('CGEventType' (aka
'enum CGEventType') and 'enum NSEventType') [-Werror,-Wenum-compare]
  122 |     if (type == NSEventTypeGesture)
      |         ~~~~ ^  ~~~~~~~~~~~~~~~~~~
1 error generated.

> Task :graphics:ccMacGlass FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':graphics:ccMacGlass'.

Is this a bug? I am not sure of the purpose of this code but as far as
I know CGEventType is not 'toll-free bridged' to NSEventType and I
don't see a CGEventType that corresponds to NSEventTypeGesture. So
potentially this branch could be taken incorrectly - or it may be
absolutely fine.

Peter

For info I am using these versions:

% javac -version
javac 23.0.2

% cc --version
Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

% sw_vers
ProductName:        macOS
ProductVersion:        15.5
BuildVersion:        24F74

% git show --oneline -s
5b659f58e5 (HEAD -> master, upstream/master) 8354631: [macos]
OpenURIHandler events not received by AWT when JavaFX is primary
toolkit

(I know I should ideally be using JDK24 for this but it's not in
homebrew yet and I don't think this problem in the native code is
caused by a Java version mismatch)

From tsayao at openjdk.org  Sat May 17 12:07:19 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 17 May 2025 12:07:19 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v21]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <nQFHAUAUEju3YWqD48R7XnbhkrQWgBvTJIds6gLN2_Q=.9c57cbf4-cee9-4140-b957-344a057a6050@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8354943
 - - Fixes on TestStage
 - - Review fixes
   - Fix Focus
   - Improvements on TestStage to assist testing
 - Merge branch 'master' into 8354943
 - Fix non-debug build
 - Review fixes
 - Fix TestStage conflicting value listener
 - Merge master
 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	tests/system/src/test/java/test/javafx/scene/RestoreSceneSizeTest.java
 - TestStage
 - ... and 13 more: https://git.openjdk.org/jfx/compare/5b659f58...9f2d17fa

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=20
  Stats: 4135 lines in 28 files changed: 2881 ins; 749 del; 505 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From pavelturk2000 at gmail.com  Sat May 17 12:18:42 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Sat, 17 May 2025 15:18:42 +0300
Subject: CodeArea: how to convert offset to TextPos?
In-Reply-To: <BYAPR10MB3013772CB633B370812C4E9DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <9a9c0e3a-70ee-4fa1-b967-cd44f40402f7@gmail.com>
 <BYAPR10MB3013772CB633B370812C4E9DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <6349bfc6-e077-48b2-a597-ea52a9719598@gmail.com>

Andy, while implementing the conversion from TextPos to offset, I encountered the following issue.

Paragraph lines do not include line separators (\n or \r\n) at the end. However, in order to correctly
calculate the offset, I need to account for the size of the line separator, which can be either 1 or 2
characters long.

In RichTextFX, as far as I know, only \n is used (i.e., \r\n is replaced with \n). But what about the JavaFX CodeArea?
How can I determine the size of the line separator there? Or is it always 1 byte as well?

Best regards, Pavel

On 5/7/25 20:04, Andy Goryachev wrote:
>
> There is no dedicated method to do that.? The application can iterate over paragraphs to compute the text position, just keep in mind that the model can be quite large and it a) will take a lot of iterations and b) the result may exceed 2^31 (i.e. need to be 'long').
>
> The same is true for the reverse operation, TextPos -> offset.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, May 7, 2025 at 09:29
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *CodeArea: how to convert offset to TextPos?
>
> Could anyone say how to convert offset to TextPos in CodeArea?
>
> For example, in RTFX CodeArea we have:
>
> var pos = codeArea.offsetToPosition(offset, Bias.Backward);
> var paragraph = pos.getMajor();
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250517/fcf102aa/attachment.htm>

From mstrauss at openjdk.org  Sat May 17 12:24:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 17 May 2025 12:24:46 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v3]
In-Reply-To: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
Message-ID: <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>

> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
> 
> The following program demonstrates the defect:
> 
> 
> public class FailingAnimationTimer extends Application {
>     @Override
>     public void start(Stage stage) throws Exception {
>         var button = new Button("start timer");
>         button.setOnAction(_ -> {
>             var timer = new AnimationTimer() {
>                 @Override
>                 public void handle(long l) {
>                     throw new RuntimeException("foo");
>                 }
>             };
> 
>             timer.start();
>         });
> 
>         var root = new HBox();
>         root.getChildren().add(new TextField("test"));
>         root.getChildren().add(button);
>         stage.setScene(new Scene(root));
>         stage.show();
>     }
> }
> 
> 
> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
> 
> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
> 
> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`

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

  remove system property

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1811/files
  - new: https://git.openjdk.org/jfx/pull/1811/files/918b0606..4722b6c4

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

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

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

From mstrauss at openjdk.org  Sat May 17 12:24:47 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 17 May 2025 12:24:47 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
 <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
 <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>
Message-ID: <qkxE34XW9n8W0y-REly3XwUTw2P8l4fU0DJXk4ZkmEI=.e0062396-5336-493b-8a45-53115290e36f@github.com>

On Fri, 16 May 2025 19:18:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> It just seems unnecessary to add all this complexity.  The first exception is all we need, really - we can skip the 2nd, 3rd, ...  This might rule out the property.
>> 
>> It might be unlikely that two or more completely unrelated failures would happen in the field in a well-tested application [citation needed], I think there is a little value in trying to add this complex logic per timer.  A static boolean might suffice.
>
> On the other hand, AnimationTimer is a public API that allows for arbitrary code execution, which always has the potential to fail for any number of reasons (think of calling an unstable API from the timer callback). We can?t rule that out entirely. This is only a fallback in any case, as a well-tested application shouldn?t throw exceptions from timer callbacks in the first place.

I've removed the system property, so there's a hard-coded limit of 100 exceptions now.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2094109661

From kevin.rushforth at oracle.com  Sat May 17 14:06:05 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 17 May 2025 07:06:05 -0700
Subject: Error building from source on Mac
In-Reply-To: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>
References: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>
Message-ID: <82d686cc-cb15-47fe-9590-f25d23a0c2a8@oracle.com>

I presume this is Xcode 16? This is a bug in our code that we will need 
to fix.

GlassTouches is currently dead code and will either be removed or 
reworked at some point. See?JDK-8238435, [2] which also has a comment 
from Martin Fox pointing out that this will no longer compile with Xcode 
16. This might be a good reason to do that.

As an FYI, we currently use Xcode 14 (14.3.1 to be precise) for our 
production builds and are in the final testing stages of updating to 
Xcode 15.4 to match JDK 25. See Draft PR 1798 [1], which I plan to take 
out of Draft early next week. We will at some point want to start 
building with Xcode 16, so we do want to fix this bug.

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1798
[2] https://bugs.openjdk.org/browse/JDK-8238435

On 5/17/2025 2:26 AM, Peter Hull wrote:
> If I checkout from git and attempt to build with `sh gradlew` I get this error:
>
> /Projects/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m:122:14:
> error: comparison of different enumeration types ('CGEventType' (aka
> 'enum CGEventType') and 'enum NSEventType') [-Werror,-Wenum-compare]
>    122 |     if (type == NSEventTypeGesture)
>        |         ~~~~ ^  ~~~~~~~~~~~~~~~~~~
> 1 error generated.
>
>> Task :graphics:ccMacGlass FAILED
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':graphics:ccMacGlass'.
>
> Is this a bug? I am not sure of the purpose of this code but as far as
> I know CGEventType is not 'toll-free bridged' to NSEventType and I
> don't see a CGEventType that corresponds to NSEventTypeGesture. So
> potentially this branch could be taken incorrectly - or it may be
> absolutely fine.
>
> Peter
>
> For info I am using these versions:
>
> % javac -version
> javac 23.0.2
>
> % cc --version
> Apple clang version 17.0.0 (clang-1700.0.13.3)
> Target: arm64-apple-darwin24.5.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> % sw_vers
> ProductName:        macOS
> ProductVersion:        15.5
> BuildVersion:        24F74
>
> % git show --oneline -s
> 5b659f58e5 (HEAD -> master, upstream/master) 8354631: [macos]
> OpenURIHandler events not received by AWT when JavaFX is primary
> toolkit
>
> (I know I should ideally be using JDK24 for this but it's not in
> homebrew yet and I don't think this problem in the native code is
> caused by a Java version mismatch)


From martinfox656 at gmail.com  Sat May 17 16:59:12 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sat, 17 May 2025 09:59:12 -0700
Subject: Error building from source on Mac
In-Reply-To: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>
References: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>
Message-ID: <D2250DCE-2FB2-48B1-BDA5-A2BB77A922D9@gmail.com>

The most recent version of Xcode enabled a new diagnostic which caught this old problem. Whether it?s a logic error or not is beside the point since the code was disabled years ago (see JDK-8231513 and JDK-8238435). I agree with Kevin that the best short-term solution is to remove the GlassTouches code entirely which is easy enough to do. I?ll make sure a PR gets submitted in the next couple of days.

> On May 17, 2025, at 2:26?AM, Peter Hull <peterhull90 at gmail.com> wrote:
> 
> If I checkout from git and attempt to build with `sh gradlew` I get this error:
> 
> /Projects/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassTouches.m:122:14:
> error: comparison of different enumeration types ('CGEventType' (aka
> 'enum CGEventType') and 'enum NSEventType') [-Werror,-Wenum-compare]
>  122 |     if (type == NSEventTypeGesture)
>      |         ~~~~ ^  ~~~~~~~~~~~~~~~~~~
> 1 error generated.
> 
>> Task :graphics:ccMacGlass FAILED
> 
> FAILURE: Build failed with an exception.
> 
> * What went wrong:
> Execution failed for task ':graphics:ccMacGlass'.
> 
> Is this a bug? I am not sure of the purpose of this code but as far as
> I know CGEventType is not 'toll-free bridged' to NSEventType and I
> don't see a CGEventType that corresponds to NSEventTypeGesture. So
> potentially this branch could be taken incorrectly - or it may be
> absolutely fine.
> 
> Peter
> 
> For info I am using these versions:
> 
> % javac -version
> javac 23.0.2
> 
> % cc --version
> Apple clang version 17.0.0 (clang-1700.0.13.3)
> Target: arm64-apple-darwin24.5.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> % sw_vers
> ProductName:        macOS
> ProductVersion:        15.5
> BuildVersion:        24F74
> 
> % git show --oneline -s
> 5b659f58e5 (HEAD -> master, upstream/master) 8354631: [macos]
> OpenURIHandler events not received by AWT when JavaFX is primary
> toolkit
> 
> (I know I should ideally be using JDK24 for this but it's not in
> homebrew yet and I don't think this problem in the native code is
> caused by a Java version mismatch)


From tsayao at openjdk.org  Sat May 17 20:21:56 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 17 May 2025 20:21:56 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v20]
In-Reply-To: <ramzefHAxO1PYnLFOzocG08KyEvzDrYkrFivWeBXNrY=.01c5a4ed-1a08-42dc-9bbb-1edf27e5f050@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <oOIOa5HQa2uvhchi-eQ783hdE7qLp4PRaUq2BWWnNZI=.542897be-13f9-4112-8a0b-89d2d65505a3@github.com>
 <ramzefHAxO1PYnLFOzocG08KyEvzDrYkrFivWeBXNrY=.01c5a4ed-1a08-42dc-9bbb-1edf27e5f050@github.com>
Message-ID: <9bVunHCRKjhVumENK_LHxvPq0vhNHgyPV1766hUhMA8=.9961fe4c-39db-4552-aab8-e02842916291@github.com>

On Sun, 11 May 2025 12:26:57 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> There are still two bugs I need to fix (that I know of):
> 
> * Popup menu grab is not working;
> * Sometimes there's a glitch of the size of the decoration on top of the view;

Last test run on Ubuntu 24.04:
- Wayland: All tests pass
- Xorg: 1 fail on  `DatePickerUpdateOnAlertCloseTest` (probably unrelated).

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2888568290

From peterhull90 at gmail.com  Sun May 18 08:20:45 2025
From: peterhull90 at gmail.com (Peter Hull)
Date: Sun, 18 May 2025 09:20:45 +0100
Subject: Error building from source on Mac
In-Reply-To: <82d686cc-cb15-47fe-9590-f25d23a0c2a8@oracle.com>
References: <CAK9Gx1f=1=4v_XuFoR3ahMmx05q8nWhKZcjHB+LN_PWgxdvxoQ@mail.gmail.com>
 <82d686cc-cb15-47fe-9590-f25d23a0c2a8@oracle.com>
Message-ID: <CAK9Gx1cfn2yZKzL=DJ_kR3+VksU3AMNoYVg68bEh7BuReVJXnQ@mail.gmail.com>

On Sat, 17 May 2025 at 20:11, Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> I presume this is Xcode 16? This is a bug in our code that we will need
> to fix.
Thank you both for the swift response. Yes, it is Xcode 16.3. I didn't
realise that code was not in use, but now I know I can comment it out
until it gets removed for real.
Peter

From mfox at openjdk.org  Sun May 18 19:06:41 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sun, 18 May 2025 19:06:41 GMT
Subject: RFR: 8238435: [macOs] Remove use of CGEventTap
Message-ID: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>

The GlassTouches code for monitoring touch events was disabled years ago because it uses a global event tap. As Apple tightened security this started generating alerts. With the latest version of Xcode (16.3) this unused code is triggering a build error. This PR removes GlassTouches entirely.

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

Commit messages:
 - Removed unused GlassTouches class

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

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

From jbhaskar at openjdk.org  Mon May 19 06:53:58 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 19 May 2025 06:53:58 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <vPtUF9nOpTJkwD-tNKTZhge-2ZsPuyy9CiizoB6Ss9o=.b1769e51-8c03-4d71-9cf1-eba071c4c30e@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

Looks good to me

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1808#pullrequestreview-2849587491

From lkostyra at openjdk.org  Mon May 19 07:06:38 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 19 May 2025 07:06:38 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v3]
In-Reply-To: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
Message-ID: <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>

> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
> 
> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
> 
> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

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

  Update regex, add tests for @0x and @-1x
  
  Capture group for the extension after scale was changed to non-capturing
  group

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1809/files
  - new: https://git.openjdk.org/jfx/pull/1809/files/64e8c2e0..39309f0d

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

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

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

From pavelturk2000 at gmail.com  Mon May 19 07:58:46 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 19 May 2025 10:58:46 +0300
Subject: Let's discuss JDK-8338952
Message-ID: <206c03a4-be9b-4e1d-ad73-5f4d193dc4c8@gmail.com>

About six months ago, I opened JDK-8338952 with a proposal to add an item comparator to (Tree)TableView.

The reason for this issue is that when using non-standard sorting ? for example, when there is a "Total"
row in the table ? the standard API becomes insufficient. One has to reinvent the wheel, and the code
quickly becomes extremely messy. Given that tables are one of the core UI components, this becomes
a serious problem.

To address this, I proposed adding an item comparator, which I believe would be very simple to implement.
I suggest we at least discuss this issue so we can start moving toward a solution.

Best regards, Pavel

From johan.vos at gluonhq.com  Mon May 19 08:40:55 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 19 May 2025 10:40:55 +0200
Subject: Headless Platform module?
In-Reply-To: <cdea6487-6cd8-4fb8-9d38-521ba5994c9e@oracle.com>
References: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>
 <cdea6487-6cd8-4fb8-9d38-521ba5994c9e@oracle.com>
Message-ID: <CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com>

Hi Kevin,

Thanks for the feedback and the valid questions.
I believe the situation is maybe a bit less complex though, because the new
headless platform does not depend on Monocle. I see it as a replacement for
the Monocle Headless sub-platform, but it has no compile-time nor run-time
dependencies on Monocle. The Monocle platform has been very valuable to
provide "simple" glass implementations for more niche-systems (including
Android, MX6, OMAP, EPD,...). One of those niche-systems is "headless".
That makes headless a special case of Monocle, and its implementation has
to follow the Monocle contracts, which are created to add native
implementations with a minimal amount of code. Therefore, the headless
Monocle subplatform is more complex than if it was a top-level platform.

Including Monocle in the standard javafx.graphics build is very hard,
because that requires compiling, linking and bundling all the native
libraries for all the subprojects (Android, MX6,...) on all platforms. For
someone who just wants to use a headless platform (e.g. for testing or
printing) on Windows, that is overkill.

Therefore, the headless platform in the sandbox does not contain native
code, and it does not extend com.sun.glass.ui.monocle.nativePlatform. It is
java code only, and depends on com.sun.glass.ui, similar to how the
gtk/mac/win platforms do.

The SPI question is an interesting one, and I've been thinking about that
as well. I believe it would be a better, more flexible approach than what
we currently do within Monocle. As said, because Monocle currently contains
native implementations for a bunch of sub-platforms, we either include
native libs for all these platforms, or for none (which makes it
unusable)). That makes it a maintenance nightmare (who is going to maintain
the OMAP code, for example?). It would be easier if each niche-platform
could have its own module, maintained by their own experts. In that case,
an SPI approach would be very convenient.
But that opens more questions and discussions, so I personally think that
is not something we have to do right now. Having the headless platform
(either in its own module or packaged into the javafx.graphics module) will
give us more experience in the different usecases, so that could bring in
the data that is needed to do the SPI approach later.

But again, I'm totally open to all approaches.

- Johan


On Sat, May 17, 2025 at 1:25?AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Interesting questions. There are two high level questions here (I
> think). First, should the Monocle headless platform be part of the
> javafx.graphics module or should it be a separate module? Second, should
> the headless "platform" be considered a completely different OS platform
> or, since it is largely platform-independent, should the headless
> platform be built and bundled with each OS. The two questions are
> somewhat related.
>
> I haven't looked at the implementation of the headless platform, so this
> is a somewhat less informed opinion than it would be once I do.
>
> As long as it is fairly small and doesn't have any public API surface
> (meaning that the only way to use it is a system property that then
> loads the Monocle glass backend along with another system property that
> selects the headless Monocle platform), it would seem easiest to leave
> it in javafx.graphics. This would mean we would start shipping the
> Monocle classes that we currently exclude as well as the new headless
> package. The second one depends on whether or not there is any native
> code associated with the headless glass platform. If not, then the
> easiest thing to do would be to always include it on all OS platforms.
>
> There might be some advantages to putting it in its own module, but
> without also moving all of Monocle to a different module, this sounds
> like a lot of work and also would raise some issues that would have to
> be solved. Would we need to define an SPI? Formalize the Monocle back
> end interfaces? Hmm.
>
> Anyway, this is just food for thought at this point.
>
> -- Kevin
>
>
> On 5/16/2025 5:14 AM, Johan Vos wrote:
> > Hi,
> >
> > The Headless Glass Platform has been in the jfx sandbox repository [1]
> > for some time now, and we have provided a number of builds allowing
> > users to test the headless platform. The reactions were very positive.
> > It's mainly being used in 2 areas: testing is obviously a major
> > usecase, especially remote testing and testing on systems where you
> > don't want a UI to popup while developing; and applications where
> > desktop functionality is used (e.g. printing, snapshots,...) without a
> > UI window being shown.
> >
> > I got a number of requests from developers who want to see this part
> > of a non-sandbox build of OpenJFX.
> > Hence, I want to start the work on adding the headless functionality
> > in the OpenJFX main repository. If you look at the diff between the
> > current head of the headless branch [1] and the master branch, you'll
> > notice it almost exclusively touches a new package:
> > com.sun.glass.ui.headless.
> > There are some minor changes in quantum and gtk, but those can be
> > handled separately.
> >
> > Before starting the work on a JEP and a PR, I'd like to discuss the
> > following: do we want the headless platform to be part of an existing
> > module (javafx.graphics), or do we want it to be part of a new module?
> > Currently, all glass platforms are part of the same module
> > (javafx.graphics), and different SDKs contain different
> > implementations -- with the Java top-level API being the same in all
> > modules.
> >
> > Apart from Monocle, there is a (non-official) 1-1 match between OS
> > platform and glass platform (e.g. linux using GTK, MacOS using mac,
> > iOS using ios,...). Therefore, the jmods, which are OS-specific, can
> > be (and are) organized in a way that they only contain the code that
> > is relevant to the target OS. It would be bad if the javafx.graphics
> > jmod for linux contained the windows-specific glass platform.
> > Monocle violates this rule, because it is platform-independent (at its
> > own top-level, that is, because inside Monocle are a bunch of
> > platform-specific components). Our "official" builds do not include
> > Monocle, but we also offer builds with monocle, and it is pretty
> > confusing. There is some logic in the current build.gradle that either
> > includes or excludes monocle from the modules.
> >
> > I want to avoid this confusion with the Headless Platform.
> > It is clear that a javafx.graphics module for MacOS should not contain
> > code for Windows, but should it contain code for Headless? I would
> > expect the answer to be "no". But then, how can developers use the
> > Headless Platform? The bad scenario is the one that currently is used
> > with monocle, where the answer is: "It depends". If you download a
> > "monocle SDK", then the javafx.graphcis jmod contains monocle, and
> > your SDK can use monocle, hence setting glass.platform=Monocle will
> > work. But with a regular build, the same will not work.
> >
> > Therefore, I believe it is worth considering the Headless Platform to
> > move into its own module. If developers want to leverage the Headless
> > Platform, they need to add the module. This requires work in the
> > javafx.graphics module, as the headless code requires access to
> > con.sun.glass.ui code, but I don't see any major issues here --
> > although I don't want to underestimate the work needed to securely add
> > "glass providers" inside javafx.graphics. The latter might open the
> > road to external glass implementations being added at runtime in
> > specific configurations.
> >
> > A drawback I see for this approach is that the Headless Platform is
> > then treated differently from the other (existing) platforms. The GTK,
> > mac, win, android, ios platforms are all part of a single module,
> > where the Headless Platform would be in its own module. As explained
> > before, there is a very good reason for this (the 1-1 match between
> > those platforms and the target system OS), so I don't see that as an
> > ugly thing.
> >
> > Before going in more detail, I'd like to hear opinions about this
> > proposal to add a new module for the Headless Platform.
> >
> > - Johan
> >
> > [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
> > [2] https://gluonhq.com/products/javafx/ , select [Headless] in JavaFX
> > version
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/427c0a51/attachment-0001.htm>

From craigraw at gmail.com  Mon May 19 09:31:58 2025
From: craigraw at gmail.com (Craig Raw)
Date: Mon, 19 May 2025 11:31:58 +0200
Subject: Headless Platform module?
In-Reply-To: <CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com>
References: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>
 <cdea6487-6cd8-4fb8-9d38-521ba5994c9e@oracle.com>
 <CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com>
Message-ID: <CAPR5oBNmUJZyQ8kjDXq9jHOZbo2sm=9tmwaFw_Fu31z7h1uuAw@mail.gmail.com>

Hi Johan,

Thanks for working on this - count me as another developer who would love
to see this part of a non-sandbox build of OpenJFX.

> It is clear that a javafx.graphics module for MacOS should not contain
code for Windows, but should it contain code for Headless? I would expect
the answer to be "no".

I am not sure the answer should be expected to be "no". Given as you say
the headless platform in the sandbox does not contain native code - Java
code only - and is to my knowledge compact as an implementation, it seems
that the simplest approach is to place it in javafx.graphics, enabled by a
system property. This will support the testing and other use cases with
minimal configuration for all existing javafx.graphics modules, and allow
immediate use without updating build plugins etc to handle a new platform.
A headless mode is useful on every platform, so including it for every
platform module is a reasonable choice.

Regardless of what you decide, excited to see the Headless Glass Platform
progressing.

- Craig


On Mon, May 19, 2025 at 10:42?AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi Kevin,
>
> Thanks for the feedback and the valid questions.
> I believe the situation is maybe a bit less complex though, because the
> new headless platform does not depend on Monocle. I see it as a replacement
> for the Monocle Headless sub-platform, but it has no compile-time nor
> run-time dependencies on Monocle. The Monocle platform has been very
> valuable to provide "simple" glass implementations for more niche-systems
> (including Android, MX6, OMAP, EPD,...). One of those niche-systems is
> "headless". That makes headless a special case of Monocle, and its
> implementation has to follow the Monocle contracts, which are created to
> add native implementations with a minimal amount of code. Therefore, the
> headless Monocle subplatform is more complex than if it was a top-level
> platform.
>
> Including Monocle in the standard javafx.graphics build is very hard,
> because that requires compiling, linking and bundling all the native
> libraries for all the subprojects (Android, MX6,...) on all platforms. For
> someone who just wants to use a headless platform (e.g. for testing or
> printing) on Windows, that is overkill.
>
> Therefore, the headless platform in the sandbox does not contain native
> code, and it does not extend com.sun.glass.ui.monocle.nativePlatform. It is
> java code only, and depends on com.sun.glass.ui, similar to how the
> gtk/mac/win platforms do.
>
> The SPI question is an interesting one, and I've been thinking about that
> as well. I believe it would be a better, more flexible approach than what
> we currently do within Monocle. As said, because Monocle currently contains
> native implementations for a bunch of sub-platforms, we either include
> native libs for all these platforms, or for none (which makes it
> unusable)). That makes it a maintenance nightmare (who is going to maintain
> the OMAP code, for example?). It would be easier if each niche-platform
> could have its own module, maintained by their own experts. In that case,
> an SPI approach would be very convenient.
> But that opens more questions and discussions, so I personally think that
> is not something we have to do right now. Having the headless platform
> (either in its own module or packaged into the javafx.graphics module) will
> give us more experience in the different usecases, so that could bring in
> the data that is needed to do the SPI approach later.
>
> But again, I'm totally open to all approaches.
>
> - Johan
>
>
> On Sat, May 17, 2025 at 1:25?AM Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>> Interesting questions. There are two high level questions here (I
>> think). First, should the Monocle headless platform be part of the
>> javafx.graphics module or should it be a separate module? Second, should
>> the headless "platform" be considered a completely different OS platform
>> or, since it is largely platform-independent, should the headless
>> platform be built and bundled with each OS. The two questions are
>> somewhat related.
>>
>> I haven't looked at the implementation of the headless platform, so this
>> is a somewhat less informed opinion than it would be once I do.
>>
>> As long as it is fairly small and doesn't have any public API surface
>> (meaning that the only way to use it is a system property that then
>> loads the Monocle glass backend along with another system property that
>> selects the headless Monocle platform), it would seem easiest to leave
>> it in javafx.graphics. This would mean we would start shipping the
>> Monocle classes that we currently exclude as well as the new headless
>> package. The second one depends on whether or not there is any native
>> code associated with the headless glass platform. If not, then the
>> easiest thing to do would be to always include it on all OS platforms.
>>
>> There might be some advantages to putting it in its own module, but
>> without also moving all of Monocle to a different module, this sounds
>> like a lot of work and also would raise some issues that would have to
>> be solved. Would we need to define an SPI? Formalize the Monocle back
>> end interfaces? Hmm.
>>
>> Anyway, this is just food for thought at this point.
>>
>> -- Kevin
>>
>>
>> On 5/16/2025 5:14 AM, Johan Vos wrote:
>> > Hi,
>> >
>> > The Headless Glass Platform has been in the jfx sandbox repository [1]
>> > for some time now, and we have provided a number of builds allowing
>> > users to test the headless platform. The reactions were very positive.
>> > It's mainly being used in 2 areas: testing is obviously a major
>> > usecase, especially remote testing and testing on systems where you
>> > don't want a UI to popup while developing; and applications where
>> > desktop functionality is used (e.g. printing, snapshots,...) without a
>> > UI window being shown.
>> >
>> > I got a number of requests from developers who want to see this part
>> > of a non-sandbox build of OpenJFX.
>> > Hence, I want to start the work on adding the headless functionality
>> > in the OpenJFX main repository. If you look at the diff between the
>> > current head of the headless branch [1] and the master branch, you'll
>> > notice it almost exclusively touches a new package:
>> > com.sun.glass.ui.headless.
>> > There are some minor changes in quantum and gtk, but those can be
>> > handled separately.
>> >
>> > Before starting the work on a JEP and a PR, I'd like to discuss the
>> > following: do we want the headless platform to be part of an existing
>> > module (javafx.graphics), or do we want it to be part of a new module?
>> > Currently, all glass platforms are part of the same module
>> > (javafx.graphics), and different SDKs contain different
>> > implementations -- with the Java top-level API being the same in all
>> > modules.
>> >
>> > Apart from Monocle, there is a (non-official) 1-1 match between OS
>> > platform and glass platform (e.g. linux using GTK, MacOS using mac,
>> > iOS using ios,...). Therefore, the jmods, which are OS-specific, can
>> > be (and are) organized in a way that they only contain the code that
>> > is relevant to the target OS. It would be bad if the javafx.graphics
>> > jmod for linux contained the windows-specific glass platform.
>> > Monocle violates this rule, because it is platform-independent (at its
>> > own top-level, that is, because inside Monocle are a bunch of
>> > platform-specific components). Our "official" builds do not include
>> > Monocle, but we also offer builds with monocle, and it is pretty
>> > confusing. There is some logic in the current build.gradle that either
>> > includes or excludes monocle from the modules.
>> >
>> > I want to avoid this confusion with the Headless Platform.
>> > It is clear that a javafx.graphics module for MacOS should not contain
>> > code for Windows, but should it contain code for Headless? I would
>> > expect the answer to be "no". But then, how can developers use the
>> > Headless Platform? The bad scenario is the one that currently is used
>> > with monocle, where the answer is: "It depends". If you download a
>> > "monocle SDK", then the javafx.graphcis jmod contains monocle, and
>> > your SDK can use monocle, hence setting glass.platform=Monocle will
>> > work. But with a regular build, the same will not work.
>> >
>> > Therefore, I believe it is worth considering the Headless Platform to
>> > move into its own module. If developers want to leverage the Headless
>> > Platform, they need to add the module. This requires work in the
>> > javafx.graphics module, as the headless code requires access to
>> > con.sun.glass.ui code, but I don't see any major issues here --
>> > although I don't want to underestimate the work needed to securely add
>> > "glass providers" inside javafx.graphics. The latter might open the
>> > road to external glass implementations being added at runtime in
>> > specific configurations.
>> >
>> > A drawback I see for this approach is that the Headless Platform is
>> > then treated differently from the other (existing) platforms. The GTK,
>> > mac, win, android, ios platforms are all part of a single module,
>> > where the Headless Platform would be in its own module. As explained
>> > before, there is a very good reason for this (the 1-1 match between
>> > those platforms and the target system OS), so I don't see that as an
>> > ugly thing.
>> >
>> > Before going in more detail, I'd like to hear opinions about this
>> > proposal to add a new module for the Headless Platform.
>> >
>> > - Johan
>> >
>> > [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>> > [2] https://gluonhq.com/products/javafx/ , select [Headless] in JavaFX
>> > version
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/76f1d813/attachment.htm>

From jhendrikx at openjdk.org  Mon May 19 10:01:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 19 May 2025 10:01:59 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v3]
In-Reply-To: <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
Message-ID: <zqWyrtU0hfIUARsquVNA__rx6rXwWOgj2Xry77cGTmc=.51d5e63b-13ea-4f1e-85f6-214fee220b4f@github.com>

On Mon, 19 May 2025 07:06:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regex, add tests for @0x and @-1x
>   
>   Capture group for the extension after scale was changed to non-capturing
>   group

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1809#pullrequestreview-2850178954

From mstrauss at openjdk.org  Mon May 19 10:30:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 19 May 2025 10:30:57 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v3]
In-Reply-To: <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
Message-ID: <KQ1XxdpHHYKccZrl0q4OpgmZyUomgJ8O_1TkGK2ojCY=.62a4d78a-5426-46d1-8b79-8f60d8fa8670@github.com>

On Mon, 19 May 2025 07:06:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regex, add tests for @0x and @-1x
>   
>   Capture group for the extension after scale was changed to non-capturing
>   group

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1809#pullrequestreview-2850260111

From kcr at openjdk.org  Mon May 19 11:58:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 11:58:00 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <9qiT-z71fjvPXOTfthfKkAyhrn_RjGxZADXKROYZGgw=.a13239ba-f71c-42fb-9a4e-29dbc36d889c@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

@arapte can you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1803#issuecomment-2890734243

From kcr at openjdk.org  Mon May 19 12:13:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 12:13:00 GMT
Subject: RFR: 8238435: [macOs] Remove use of CGEventTap
In-Reply-To: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
References: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
Message-ID: <anQZUcCUJtZkIcX4wKO511ucgbN_KUYHSTbB2KumbDw=.c13c5dbf-c65a-4a22-8190-a0b2b0f94bd6@github.com>

On Sun, 18 May 2025 19:02:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassTouches code for monitoring touch events was disabled years ago because it uses a global event tap. As Apple tightened security this started generating alerts. With the latest version of Xcode (16.3) this unused code is triggering a build error. This PR removes GlassTouches entirely.

@beldenfox Thanks for taking this one. I'll review it, but I'd also like a second reviewer.

The code changes look good. I'll run a couple tests  in the next day or two.

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

PR Comment: https://git.openjdk.org/jfx/pull/1812#issuecomment-2890776910

From kcr at openjdk.org  Mon May 19 13:44:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 13:44:03 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v3]
In-Reply-To: <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
Message-ID: <yL1ktyhy4tI10sF77vm4b7mlwyXuPaz4M8gtSlYN2qc=.575a9f52-68b7-456e-b966-c17f26310ffd@github.com>

On Mon, 19 May 2025 07:06:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regex, add tests for @0x and @-1x
>   
>   Capture group for the extension after scale was changed to non-capturing
>   group

@lukostyra Can you rerun your GitHub action build? It failed with an intermittent network error when trying to run the gradle-wrapper verification task.

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

PR Comment: https://git.openjdk.org/jfx/pull/1809#issuecomment-2891084689

From angorya at openjdk.org  Mon May 19 14:22:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 14:22:58 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
Message-ID: <dv5a1orgjE4H3-TYOa_QIwXKdaNPj5SsYdX4A3voeGE=.f5fb9ad0-e21f-4e3c-b539-a356c2044d67@github.com>

On Fri, 16 May 2025 22:25:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
>> 
>> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second try at making Keyman work to some extent

Thank you for clarification!

This PR fixes the issues with multiple keyman keyboards without introducing regressions with the normal keyboard or the IME.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1805#pullrequestreview-2850953021

From lkostyra at openjdk.org  Mon May 19 14:27:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 19 May 2025 14:27:56 GMT
Subject: RFR: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level [v3]
In-Reply-To: <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
 <EvyE9UTewl63NSOCnl8_BpF_1ZaXX88V5QTZWKVJxLA=.7073d5fa-44ae-4b2f-a35c-debb63aa39e5@github.com>
Message-ID: <mF_DapROKOl39QPVqzE8euE-Mgt1Y9kabc-zFMQTsTM=.dd2c845f-cee3-4d27-a101-c0931a191456@github.com>

On Mon, 19 May 2025 07:06:38 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
>> 
>> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
>> 
>> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regex, add tests for @0x and @-1x
>   
>   Capture group for the extension after scale was changed to non-capturing
>   group

All checks passed so I'll merge this one. Thanks for review everyone!

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

PR Comment: https://git.openjdk.org/jfx/pull/1809#issuecomment-2891234299

From lkostyra at openjdk.org  Mon May 19 14:27:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 19 May 2025 14:27:56 GMT
Subject: Integrated: 8342530: Specifying "@Nx" scaling level in ImageStorage
 should only load that specific level
In-Reply-To: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
References: <rfIb8IyAwlAD_hIgVs0vL1tw_fg9_xP-bCLrgjf7Ma0=.f70f4a1c-6966-4515-9efa-bcee53ca02df@github.com>
Message-ID: <mv-CYYH4CkSHn-l35sLfy7Kh9LDFxh0AebiCRZyC2jk=.d7e7d74e-bd7b-4e4a-9a17-dca92d237fec@github.com>

On Thu, 15 May 2025 11:27:21 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This follow-up change finishes the earlier changes to `ImageStorage.loadAll()` and adds support for loading specific scale requested in the input.
> 
> `loadAll()` will now first check if the input path ends with a scaling level specified, and if that is the case it will attempt creating a Stream. If requested resource does not exist it will throw an Exception, skipping the rest of the load process. If the resource does _not_ have a scaled name in its path, it will continue loading as normal - looking for all scale levels, trying to load the main resource and falling back to trying to load "@1x" variant.
> 
> Added tests to check the new `ImageTools.hasScaledName()` method + new behavior.

This pull request has now been integrated.

Changeset: 3299949c
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3299949c2f8921432fc25bf125bae37f149d032d
Stats:     63 lines in 4 files changed: 55 ins; 0 del; 8 mod

8342530: Specifying "@Nx" scaling level in ImageStorage should only load that specific level

Reviewed-by: mstrauss, jhendrikx

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

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

From kevin.rushforth at oracle.com  Mon May 19 15:13:04 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 May 2025 08:13:04 -0700
Subject: [External] : Re: Headless Platform module?
In-Reply-To: <CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com>
References: <CABxFH2FJgkVA35So8+yR1m79qM9E=g2sFrTendbC807mSm+T-g@mail.gmail.com>
 <cdea6487-6cd8-4fb8-9d38-521ba5994c9e@oracle.com>
 <CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com>
Message-ID: <e5414912-ab51-4958-b210-c580ba6a574e@oracle.com>


> I believe the situation is maybe a bit less complex though, because 
> the new headless platform does not depend on Monocle. I see it as a 
> replacement for the Monocle Headless sub-platform, but it has no 
> compile-time nor run-time dependencies on Monocle.

Oh, that does simplify things a fair bit -- and is a good illustration 
of my opinion being "less informed" than it might be. :)

Given that there is no dependency on Monocle (good), no native code 
(also good), and no public API (very good), then I don't think it 
matters as much whether it is part of javafx.graphics or a new module 
(if a new module, the qualified exports needed to put it in its own 
module should be straightforward). I might have additional thoughts 
after I look at the code, but as of now either approach seems fine.

And you are right that either way you end up going with this, it will 
give some additional experience that could inform what happens to 
Monocle in the future.

-- Kevin

On 5/19/2025 1:40 AM, Johan Vos wrote:
> Hi Kevin,
>
> Thanks for the feedback and the valid questions.
> I believe the situation is maybe a bit less complex though, because 
> the new headless platform does not depend on Monocle. I see it as a 
> replacement for the Monocle Headless sub-platform, but it has no 
> compile-time nor run-time dependencies on Monocle. The Monocle 
> platform has been very valuable to provide "simple" glass 
> implementations for more niche-systems (including Android, MX6, OMAP, 
> EPD,...). One of those niche-systems is "headless". That makes 
> headless a special case of Monocle, and its implementation has to 
> follow the Monocle contracts, which are created to add native 
> implementations with a minimal amount of code. Therefore, the headless 
> Monocle subplatform?is more complex than if it was a top-level platform.
>
> Including Monocle in the standard javafx.graphics?build is very hard, 
> because that requires compiling, linking and bundling all the native 
> libraries for all the subprojects (Android, MX6,...) on all platforms. 
> For someone who just wants to use a headless platform (e.g. for 
> testing or printing) on Windows, that is overkill.
>
> Therefore, the headless platform in the sandbox does not contain 
> native code, and it does not 
> extend?com.sun.glass.ui.monocle.nativePlatform. It is java code only, 
> and depends on com.sun.glass.ui, similar to how the gtk/mac/win 
> platforms do.
>
> The SPI question is an interesting one, and I've been thinking about 
> that as well. I believe it would be a better, more flexible approach 
> than what we currently do within Monocle. As said, because Monocle 
> currently contains native implementations for a bunch of 
> sub-platforms, we either include native libs for all these platforms, 
> or for none (which makes it unusable)). That makes it a maintenance 
> nightmare (who is going to maintain the OMAP code, for example?). It 
> would be easier if each niche-platform could have its own module, 
> maintained by their own experts. In that case, an SPI approach would 
> be very convenient.
> But that opens more questions and discussions, so I personally think 
> that is not something we have to do right now. Having the headless 
> platform (either in its own module or packaged into the 
> javafx.graphics module) will give us more experience in the different 
> usecases, so that could bring in the data that is needed to do the SPI 
> approach later.
>
> But again, I'm totally open to all approaches.
>
> - Johan
>
>
> On Sat, May 17, 2025 at 1:25?AM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     Interesting questions. There are two high level questions here (I
>     think). First, should the Monocle headless platform be part of the
>     javafx.graphics module or should it be a separate module? Second,
>     should
>     the headless "platform" be considered a completely different OS
>     platform
>     or, since it is largely platform-independent, should the headless
>     platform be built and bundled with each OS. The two questions are
>     somewhat related.
>
>     I haven't looked at the implementation of the headless platform,
>     so this
>     is a somewhat less informed opinion than it would be once I do.
>
>     As long as it is fairly small and doesn't have any public API surface
>     (meaning that the only way to use it is a system property that then
>     loads the Monocle glass backend along with another system property
>     that
>     selects the headless Monocle platform), it would seem easiest to
>     leave
>     it in javafx.graphics. This would mean we would start shipping the
>     Monocle classes that we currently exclude as well as the new headless
>     package. The second one depends on whether or not there is any native
>     code associated with the headless glass platform. If not, then the
>     easiest thing to do would be to always include it on all OS platforms.
>
>     There might be some advantages to putting it in its own module, but
>     without also moving all of Monocle to a different module, this sounds
>     like a lot of work and also would raise some issues that would
>     have to
>     be solved. Would we need to define an SPI? Formalize the Monocle back
>     end interfaces? Hmm.
>
>     Anyway, this is just food for thought at this point.
>
>     -- Kevin
>
>
>     On 5/16/2025 5:14 AM, Johan Vos wrote:
>     > Hi,
>     >
>     > The Headless Glass Platform has been in the jfx sandbox
>     repository [1]
>     > for some time now, and we have provided a number of builds allowing
>     > users to test the headless platform. The reactions were very
>     positive.
>     > It's mainly being used in 2 areas: testing is obviously a major
>     > usecase, especially remote testing and testing on systems where you
>     > don't want a UI to popup while developing; and applications where
>     > desktop functionality is used (e.g. printing, snapshots,...)
>     without a
>     > UI window being shown.
>     >
>     > I got a number of requests from developers who want to see this
>     part
>     > of a non-sandbox build of OpenJFX.
>     > Hence, I want to start the work on adding the headless
>     functionality
>     > in the OpenJFX main repository. If you look at the diff between the
>     > current head of the headless branch [1] and the master branch,
>     you'll
>     > notice it almost exclusively touches a new package:
>     > com.sun.glass.ui.headless.
>     > There are some minor changes in quantum and gtk, but those can be
>     > handled separately.
>     >
>     > Before starting the work on a JEP?and a PR, I'd like to discuss the
>     > following: do we want the headless platform to be part of an
>     existing
>     > module (javafx.graphics), or do we want it to be part of a new
>     module?
>     > Currently, all glass platforms are part of the same module
>     > (javafx.graphics), and different SDKs contain different
>     > implementations -- with the Java top-level API being the same in
>     all
>     > modules.
>     >
>     > Apart from Monocle, there is a (non-official) 1-1 match between OS
>     > platform and glass platform (e.g. linux using GTK, MacOS using mac,
>     > iOS using ios,...). Therefore, the jmods, which are OS-specific,
>     can
>     > be (and are) organized in a way that they only contain the code
>     that
>     > is relevant to the target OS. It would be bad if the
>     javafx.graphics
>     > jmod for linux contained the windows-specific glass platform.
>     > Monocle violates this rule, because it is platform-independent
>     (at its
>     > own top-level, that is, because inside Monocle are a bunch of
>     > platform-specific components). Our "official" builds do not include
>     > Monocle, but we also offer builds with monocle, and it is pretty
>     > confusing. There is some logic in the current build.gradle that
>     either
>     > includes or excludes monocle from the modules.
>     >
>     > I want to avoid this confusion with the Headless Platform.
>     > It is clear that a javafx.graphics module for MacOS should not
>     contain
>     > code for Windows, but should it contain code for Headless? I would
>     > expect the answer to be "no". But then, how can developers use the
>     > Headless Platform? The bad scenario is the one that currently is
>     used
>     > with monocle, where the answer is: "It depends". If you download a
>     > "monocle SDK", then the javafx.graphcis jmod?contains monocle, and
>     > your SDK can use monocle, hence setting glass.platform=Monocle will
>     > work. But with a regular build, the same will not work.
>     >
>     > Therefore, I believe it is worth considering the Headless
>     Platform to
>     > move into its own module. If developers want to leverage the
>     Headless
>     > Platform, they need to add the module. This requires work in the
>     > javafx.graphics module, as the headless code requires access to
>     > con.sun.glass.ui code, but I don't see any major issues here --
>     > although I don't want to underestimate the work needed to
>     securely add
>     > "glass providers" inside javafx.graphics. The latter might open the
>     > road to external glass implementations being added at runtime in
>     > specific configurations.
>     >
>     > A drawback I see for this approach is that the Headless Platform is
>     > then treated differently from the other (existing) platforms.
>     The GTK,
>     > mac, win, android, ios platforms are all part of a single module,
>     > where the Headless Platform would be in its own module. As
>     explained
>     > before, there is a very good reason for this (the 1-1 match between
>     > those platforms and the target system OS), so I don't see that
>     as an
>     > ugly thing.
>     >
>     > Before going in more detail, I'd like to hear opinions about this
>     > proposal to add a new module for the Headless Platform.
>     >
>     > - Johan
>     >
>     > [1]
>     https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>     <https://urldefense.com/v3/__https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVwB42e1Cg$>
>     > [2] https://gluonhq.com/products/javafx/
>     <https://urldefense.com/v3/__https://gluonhq.com/products/javafx/__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVxD8BKC8Q$>
>     , select [Headless] in JavaFX
>     > version
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/bf65583f/attachment-0001.htm>

From angorya at openjdk.org  Mon May 19 15:20:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 15:20:59 GMT
Subject: RFR: 8238435: [macOs] Remove use of CGEventTap
In-Reply-To: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
References: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
Message-ID: <fycddomAgOl7inMUanG6fMWo3g4Ur7qCOtve4Lk1xk0=.1e32f626-3c91-48e2-9eb3-f59b2f19a3a7@github.com>

On Sun, 18 May 2025 19:02:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassTouches code for monitoring touch events was disabled years ago because it uses a global event tap. As Apple tightened security this started generating alerts. With the latest version of Xcode (16.3) this unused code is triggering a build error. This PR removes GlassTouches entirely.

The code changes look good to me;  did not see any regression running jfx built with XCODE version: Xcode14.3.1+1.0

command line:

(rm -rf ./build ; gradle -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true clean all 2>&1) | tee ~/`date +"build-full-%Y-%m%d-%H%M%S"`.log


(I don't not want to upgrade XCode yet)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1812#pullrequestreview-2851156408

From angorya at openjdk.org  Mon May 19 15:32:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 15:32:58 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <qkxE34XW9n8W0y-REly3XwUTw2P8l4fU0DJXk4ZkmEI=.e0062396-5336-493b-8a45-53115290e36f@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
 <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
 <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>
 <qkxE34XW9n8W0y-REly3XwUTw2P8l4fU0DJXk4ZkmEI=.e0062396-5336-493b-8a45-53115290e36f@github.com>
Message-ID: <ilK0kAHiz9kO28z8NNpOOIKpVIaaAPjvLTgVKhEMUHE=.a9cd9590-9a0d-42e6-a68d-8147ff58c1fd@github.com>

On Sat, 17 May 2025 12:21:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> On the other hand, AnimationTimer is a public API that allows for arbitrary code execution, which always has the potential to fail for any number of reasons (think of calling an unstable API from the timer callback). We can?t rule that out entirely. This is only a fallback in any case, as a well-tested application shouldn?t throw exceptions from timer callbacks in the first place.
>
> I've removed the system property, so there's a hard-coded limit of 100 exceptions now.

100 still looks excessive to me - it's unlikely that we'll have two different scenarios when this happens, so most of the time the log will have 100 identical traces.

I mean, one is probably enough, we could have 2 or 4 just to drive the message home.  Anything beyond 8 is simply annoying, don't you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2095993342

From kcr at openjdk.org  Mon May 19 16:02:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 16:02:09 GMT
Subject: RFR: 8355740: Update to Xcode 15.4 on macOS
Message-ID: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>

This PR updates the compiler on macOS to Xcode 15.4 (from 14.3.1) to match JDK 25.

I ran a full headless and headful test run, including building media and WebKit. No issues were found.

NOTE: Xcode 15.4 requires macOS 14 Sonoma to build (although it is known to build on macOS 13, which might be useful for developer builds). The generated JavaFX code will run on older versions of macOS.

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

Commit messages:
 - Merge branch 'master' into 8355740-xcode-15.4
 - Update GHA Xcode version
 - 8355740: Update to Xcode 15.4 on macOS

Changes: https://git.openjdk.org/jfx/pull/1798/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1798&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355740
  Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1798.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1798/head:pull/1798

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

From kcr at openjdk.org  Mon May 19 16:02:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 16:02:10 GMT
Subject: RFR: 8355740: Update to Xcode 15.4 on macOS
In-Reply-To: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
References: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
Message-ID: <JWpzLBeJdjdryb78Db6WB1qE6DU302PfRI-nNyOqO4U=.78a881c6-9f5d-451c-b878-c791d18452c8@github.com>

On Mon, 28 Apr 2025 18:41:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on macOS to Xcode 15.4 (from 14.3.1) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. No issues were found.
> 
> NOTE: Xcode 15.4 requires macOS 14 Sonoma to build (although it is known to build on macOS 13, which might be useful for developer builds). The generated JavaFX code will run on older versions of macOS.

Reviewers: @arapte @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1798#issuecomment-2891533230

From kcr at openjdk.org  Mon May 19 16:14:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 16:14:06 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <T3Mc0p3OHQFrLa7kHIJaHZZ_wu4tT6cFQkyCsTP-sKU=.28674aae-2e9e-472c-9442-cdb135ce6a7a@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

Reviewers: @arapte @tiainen @sashamatveev

@sashamatveev I would like you to review the media Makefile changes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1807#issuecomment-2891569910
PR Comment: https://git.openjdk.org/jfx/pull/1807#issuecomment-2891571375

From kcr at openjdk.org  Mon May 19 16:14:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 16:14:06 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows
Message-ID: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>

This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.

I ran a full headless and headful test run, including building media and WebKit. All tests pass.

NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
 - Only define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' for ICU on Windows
 - Define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' when compiling web (ICU), graphics, and media
 - 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

Changes: https://git.openjdk.org/jfx/pull/1807/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354986
  Stats: 21 lines in 14 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1807.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1807/head:pull/1807

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

From mstrauss at openjdk.org  Mon May 19 18:07:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 19 May 2025 18:07:59 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <ilK0kAHiz9kO28z8NNpOOIKpVIaaAPjvLTgVKhEMUHE=.a9cd9590-9a0d-42e6-a68d-8147ff58c1fd@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
 <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
 <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>
 <qkxE34XW9n8W0y-REly3XwUTw2P8l4fU0DJXk4ZkmEI=.e0062396-5336-493b-8a45-53115290e36f@github.com>
 <ilK0kAHiz9kO28z8NNpOOIKpVIaaAPjvLTgVKhEMUHE=.a9cd9590-9a0d-42e6-a68d-8147ff58c1fd@github.com>
Message-ID: <_NUbT3cStB-dEkm7Vh0JMarp22IyPxXJWNgbLueqaNI=.43ef55a2-a7b6-4bd9-82f8-341f4d8b9b5c@github.com>

On Mon, 19 May 2025 15:30:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I've removed the system property, so there's a hard-coded limit of 100 exceptions now.
>
> 100 still looks excessive to me - it's unlikely that we'll have two different scenarios when this happens, so most of the time the log will have 100 identical traces.
> 
> I mean, one is probably enough, we could have 2 or 4 just to drive the message home.  Anything beyond 8 is simply annoying, don't you think?

In general, we shouldn't suppress any exceptions that would otherwise be logged. The only thing that makes this case a bit different is that with a periodic timer, there's the potential for an inflated log that grows without bounds. I think that defining a reasonable upper limit is enough to prevent that; in particular, I think we shouldn't try to assume that any particular number of logged failures (like 1 or 4) is "enough" for application developers.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2096251535

From angorya at openjdk.org  Mon May 19 18:19:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 18:19:56 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v3]
In-Reply-To: <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
Message-ID: <PY-UIMKoDJLI8A8VxJ8HgQ00JIC07UMgz3tpFtu3aWo=.c4de3a23-ea4c-4e7e-9a6f-a2b6622721b1@github.com>

On Sat, 17 May 2025 12:24:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove system property

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1811#pullrequestreview-2851647992

From angorya at openjdk.org  Mon May 19 18:19:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 18:19:57 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v2]
In-Reply-To: <_NUbT3cStB-dEkm7Vh0JMarp22IyPxXJWNgbLueqaNI=.43ef55a2-a7b6-4bd9-82f8-341f4d8b9b5c@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <XWgf-l9qLx_MmnQGWxDdDIq_IEHkImU1pTtqgSber6Y=.581d87a3-d98c-46ee-b5a2-c302b9db8086@github.com>
 <ZOjg16dyrkU9VAt4lmqHkRONtlaYH686tDHxOD0Uh7c=.506f5ba2-86d3-4831-a95a-c097741657a2@github.com>
 <x6IgoUZig0rc4c8xZEDauqLzCu7xCOQnuUFVUVqWKQQ=.5c2aa1ab-d7a4-431f-ba25-45a0926d2755@github.com>
 <5qgLqluT1zRUWBeD4nablDXZAuBBnWKbhIMyavp7zN8=.737209ce-1368-4620-ae97-0e45a39de3ea@github.com>
 <JbPymZHBCNHSYddHHrWoVQ0Jp4GN9LzjWJRTfX2690k=.b49c6b7d-722a-4926-9ed4-1d7dca5670a6@github.com>
 <1QyUBYYRO_hIWc2NJ_hJGBJ5es5jcf_bpujmLG120mM=.4f0e79b5-074f-4bb5-8c58-5b1d2e7f9a68@github.com>
 <qkxE34XW9n8W0y-REly3XwUTw2P8l4fU0DJXk4ZkmEI=.e0062396-5336-493b-8a45-53115290e36f@github.com>
 <ilK0kAHiz9kO28z8NNpOOIKpVIaaAPjvLTgVKhEMUHE=.a9cd9590-9a0d-42e6-a68d-8147ff58c1fd@github.com>
 <_NUbT3cStB-dEkm7Vh0JMarp22IyPxXJWNgbLueqaNI=.43ef55a2-a7b6-4bd9-82f8-341f4d8b9b5c@github.com>
Message-ID: <bulMda-Rb54tmt0BrRkthPdZ2Nnp8qJ50lJAal1XYns=.25736723-9b81-4a6a-a4c4-766869693327@github.com>

On Mon, 19 May 2025 18:05:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 100 still looks excessive to me - it's unlikely that we'll have two different scenarios when this happens, so most of the time the log will have 100 identical traces.
>> 
>> I mean, one is probably enough, we could have 2 or 4 just to drive the message home.  Anything beyond 8 is simply annoying, don't you think?
>
> In general, we shouldn't suppress any exceptions that would otherwise be logged. The only thing that makes this case a bit different is that with a periodic timer, there's the potential for an inflated log that grows without bounds. I think that defining a reasonable upper limit is enough to prevent that; in particular, I think we shouldn't try to assume that any particular number of logged failures (like 1 or 4) is "enough" for application developers.

well, I still think it's way too high of a number, but the expectation is that once the dev sees a 100 traces in the log they'll fix it right away.

And if some company finds that all of a sudden their client logs exploded in size, they should have invested more in QA.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1811#discussion_r2096266254

From andy.goryachev at oracle.com  Mon May 19 19:00:44 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 19 May 2025 19:00:44 +0000
Subject: CodeArea: how to convert offset to TextPos?
In-Reply-To: <6349bfc6-e077-48b2-a597-ea52a9719598@gmail.com>
References: <9a9c0e3a-70ee-4fa1-b967-cd44f40402f7@gmail.com>
 <BYAPR10MB3013772CB633B370812C4E9DE588A@BYAPR10MB3013.namprd10.prod.outlook.com>
 <6349bfc6-e077-48b2-a597-ea52a9719598@gmail.com>
Message-ID: <CY8PR10MB7265D6946ABC4AB1A7BF95ADE59CA@CY8PR10MB7265.namprd10.prod.outlook.com>

A good question!

In the RichTextArea, it generally depends on the model.  The default implementation, both in RichTextArea and CodeArea, the plaintext format handler uses "line.separator" system property (PlainTextFormatHandler:72).  That is, both will emit \r\n line separators in Windows, \n elsewhere else.

The model may decide to change that behavior and register a different data format handler, as required by the application requirements.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Saturday, May 17, 2025 at 05:19
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: how to convert offset to TextPos?
Andy, while implementing the conversion from TextPos to offset, I encountered the following issue.

Paragraph lines do not include line separators (\n or \r\n) at the end. However, in order to correctly
calculate the offset, I need to account for the size of the line separator, which can be either 1 or 2
characters long.

In RichTextFX, as far as I know, only \n is used (i.e., \r\n is replaced with \n). But what about the JavaFX CodeArea?
How can I determine the size of the line separator there? Or is it always 1 byte as well?

Best regards, Pavel
On 5/7/25 20:04, Andy Goryachev wrote:
There is no dedicated method to do that.  The application can iterate over paragraphs to compute the text position, just keep in mind that the model can be quite large and it a) will take a lot of iterations and b) the result may exceed 2^31 (i.e. need to be 'long').

The same is true for the reverse operation, TextPos -> offset.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Wednesday, May 7, 2025 at 09:29
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: how to convert offset to TextPos?
Could anyone say how to convert offset to TextPos in CodeArea?

For example, in RTFX CodeArea we have:

var pos = codeArea.offsetToPosition(offset, Bias.Backward);
var paragraph = pos.getMajor();

Best regards, Pavel

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

From andy.goryachev at oracle.com  Mon May 19 19:28:21 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 19 May 2025 19:28:21 +0000
Subject: Let's discuss JDK-8338952
In-Reply-To: <206c03a4-be9b-4e1d-ad73-5f4d193dc4c8@gmail.com>
References: <206c03a4-be9b-4e1d-ad73-5f4d193dc4c8@gmail.com>
Message-ID: <CY8PR10MB7265AF87360AE4754C57D709E59CA@CY8PR10MB7265.namprd10.prod.outlook.com>

One possible solution would be to deprecate the comparator property (not for removal, keep it for backward compatibility), and add a new property 'sortPolicy' which will use an interface that can be evolved, as opposed to a naive callback.

public interface SortPolicy<ITEM,VALUE> {
    public int compare(ITEM itemA, VALUE valueA, ITEM itemB, VALUE valueB);
}

when set, the new property will override the comparator property.

What do you think?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 19, 2025 at 00:59
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Let's discuss JDK-8338952
About six months ago, I opened JDK-8338952 with a proposal to add an item comparator to (Tree)TableView.

The reason for this issue is that when using non-standard sorting ? for example, when there is a "Total"
row in the table ? the standard API becomes insufficient. One has to reinvent the wheel, and the code
quickly becomes extremely messy. Given that tables are one of the core UI components, this becomes
a serious problem.

To address this, I proposed adding an item comparator, which I believe would be very simple to implement.
I suggest we at least discuss this issue so we can start moving toward a solution.

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/96606a9a/attachment.htm>

From kcr at openjdk.org  Mon May 19 19:39:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 May 2025 19:39:53 GMT
Subject: RFR: 8238435: [macOs] Remove use of CGEventTap
In-Reply-To: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
References: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
Message-ID: <WKFdKR66bVGUC3Q_pbnUn9GD_oXJH-LAzMcbREHpe9g=.75e0891b-0a6d-4e9e-9f6d-c534d4bb1aac@github.com>

On Sun, 18 May 2025 19:02:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassTouches code for monitoring touch events was disabled years ago because it uses a global event tap. As Apple tightened security this started generating alerts. With the latest version of Xcode (16.3) this unused code is triggering a build error. This PR removes GlassTouches entirely.

Looks good. I can confirm that with Xcode 16.3 this fails to compile without this fix and works with this fix. Since GlassTouches is currently disabled on all supported platforms (and has been for years), this will not have any negative impact.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1812#pullrequestreview-2851802698

From almatvee at openjdk.org  Mon May 19 20:22:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 19 May 2025 20:22:57 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <dNUShtJKkv8Pb5ddREEs22QFOUdXdooKCrZeQoIVohU=.887c4c1b-6cf2-4202-8f71-be244f32e8c5@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

Media changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2851902349

From angorya at openjdk.org  Mon May 19 22:14:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 May 2025 22:14:08 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy
Message-ID: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@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 positions within the text layout.
 *
 * @since 999 TODO
 */
public class TabStopPolicy {
    /**
     * Constructs a new {@code TabStopPolicy} instance.
     */
    public TabStopPolicy() {

    /**
     * Specifies the unmodifiable list of tab stops, sorted by position from smallest to largest.
     * The list can be changed using
     *
     * @return the non-null, unmodifiable list of tab stops, sorted by position
     */
    public final ObservableList<TabStop> tabStops() {

    /**
     * Provides default tab stops (beyond the last tab stop specified by {@code #tabStops()},
     * as a fixed repeating distance in pixels from the last tab stop position.
     * The position of default tab stops is computed at regular intervals relative to
     * the leading edge of the {@code TextFlow} this policy is registered with.
     * <p>
     * The value of less than or equal 0 disables the default stops.
     *
     * @return the default tab stops property
     * @defaultValue 0
     */
    public final DoubleProperty defaultStopsProperty() {

    public final double getDefaultStops() {

    public final void setDefaultStops(double value) {


### TabStop


/**
 * This class encapsulates an immutable single tab stop within the {@link TabStopPolicy}.
 * <p>
 * A tab stop is at a specified distance from the
 * left margin, aligns text in a specified way, and has a specified leader.
 *
 * @since 999 TODO
 */
public class TabStop {
    /**
     * Constructs a new tab stop with the specified position.
     *
     * @param position the position in pixels
     */
    public TabStop(double position) {

    /**
     * Returns the position, in pixels, of the tab.
     * @return the position of the tab
     */
    public final double getPosition() {



## Alternatives

None known.



## Risks and Assumptions

Possible incompatibility with custom controls which extend `TextFlow` and declare a property with the same name. 



## Dependencies

None.



## References

0. [JDK-8314482](https://bugs.openjdk.org/browse/JDK-8314482)
1. https://github.com/andy-goryachev-oracle/Test/blob/main/doc/TabStopPolicy/TabStopPolicy.md

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

Commit messages:
 - 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
 - wired
 - moved
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - local to scene
 - ... and 45 more: https://git.openjdk.org/jfx/compare/3299949c...d624df53

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314482
  Stats: 658 lines in 12 files changed: 592 ins; 37 del; 29 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 tsayao at openjdk.org  Mon May 19 23:02:59 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 19 May 2025 23:02:59 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v21]
In-Reply-To: <nQFHAUAUEju3YWqD48R7XnbhkrQWgBvTJIds6gLN2_Q=.9c57cbf4-cee9-4140-b957-344a057a6050@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <nQFHAUAUEju3YWqD48R7XnbhkrQWgBvTJIds6gLN2_Q=.9c57cbf4-cee9-4140-b957-344a057a6050@github.com>
Message-ID: <Vruzi-X7PV1oYpOjdz8TCKJMGIvrlBTTwwQ81LjOvFQ=.52b38f6c-b843-482b-8b05-ac32a05f418e@github.com>

On Sat, 17 May 2025 12:07:19 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into 8354943
>  - - Fixes on TestStage
>  - - Review fixes
>    - Fix Focus
>    - Improvements on TestStage to assist testing
>  - Merge branch 'master' into 8354943
>  - Fix non-debug build
>  - Review fixes
>  - Fix TestStage conflicting value listener
>  - Merge master
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	tests/system/src/test/java/test/javafx/scene/RestoreSceneSizeTest.java
>  - TestStage
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/5b659f58...9f2d17fa

There are some failing tests on Ubuntu 20.04 (Xorg) that I need to look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2892470218

From mfox at openjdk.org  Mon May 19 23:03:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 19 May 2025 23:03:58 GMT
Subject: Integrated: 8238435: [macOs] Remove use of CGEventTap
In-Reply-To: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
References: <5jQ2PK3oTF2bE_GV2TDmD2X1rvtvjjIBLROt7ZjnrLo=.13166117-40a8-4221-8f72-0ecbbd0bcac4@github.com>
Message-ID: <_y0djrUnnXfIMRmLH_88u6_yedOOTXxwd2vO9MICdPw=.2a313299-a57c-432f-a119-5481242e9406@github.com>

On Sun, 18 May 2025 19:02:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassTouches code for monitoring touch events was disabled years ago because it uses a global event tap. As Apple tightened security this started generating alerts. With the latest version of Xcode (16.3) this unused code is triggering a build error. This PR removes GlassTouches entirely.

This pull request has now been integrated.

Changeset: ce0b9e83
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ce0b9e83673049e72c0b9f5d7265434044faeb59
Stats:     508 lines in 6 files changed: 0 ins; 508 del; 0 mod

8238435: [macOs] Remove use of CGEventTap

Reviewed-by: angorya, kcr

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

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

From pavelturk2000 at gmail.com  Tue May 20 00:20:56 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 20 May 2025 03:20:56 +0300
Subject: Let's discuss JDK-8338952
In-Reply-To: <CY8PR10MB7265AF87360AE4754C57D709E59CA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <206c03a4-be9b-4e1d-ad73-5f4d193dc4c8@gmail.com>
 <CY8PR10MB7265AF87360AE4754C57D709E59CA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <b6431603-da1d-4210-8944-7317aaeb3e33@gmail.com>

Andy, I think this is a good solution because it provides everything needed for sorting.
Moreover, it complies with the generics of TableColumn.

For example,

var column = new TableColumn<Person, String>("First Name");
SortPolicy<Person, String> sortPolicy = ...
column.setSortPolicy(sortPolicy);

But don't you think the VALUE parameters are redundant since they can be obtained directly from ITEM?

Best regards, Pavel

On 5/19/25 22:28, Andy Goryachev wrote:
>
> One possible solution would be to deprecate the comparator property (not for removal, keep it for backward compatibility), and add a new property 'sortPolicy' which will use an interface that can be evolved, as opposed to a naive callback.
>
> public interface SortPolicy<ITEM,VALUE> {
>
> public int compare(ITEM itemA, VALUE valueA, ITEM itemB, VALUE valueB);
>
> }
>
> when set, the new property will override the comparator property.
>
> What do you think?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, May 19, 2025 at 00:59
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Let's discuss JDK-8338952
>
> About six months ago, I opened JDK-8338952 with a proposal to add an item comparator to (Tree)TableView.
>
> The reason for this issue is that when using non-standard sorting ? for example, when there is a "Total"
> row in the table ? the standard API becomes insufficient. One has to reinvent the wheel, and the code
> quickly becomes extremely messy. Given that tables are one of the core UI components, this becomes
> a serious problem.
>
> To address this, I proposed adding an item comparator, which I believe would be very simple to implement.
> I suggest we at least discuss this issue so we can start moving toward a solution.
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250520/778b061e/attachment.htm>

From duke at openjdk.org  Tue May 20 04:25:01 2025
From: duke at openjdk.org (Marc Durdin)
Date: Tue, 20 May 2025 04:25:01 GMT
Subject: RFR: 8356652: Input field ignores custom input source characters
 [v2]
In-Reply-To: <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
References: <3RZ7VY8uVlZF73nBTQuEo0SymHXcsNOODHymQlv0w7Q=.9e9764a6-4f27-4ea4-9c7e-ac8f14edc743@github.com>
 <eX0CANVWLxmqS2d0BLlsc3qdWVszynah1nEOSlhdBKE=.2481d69c-da36-4048-83b2-96818aeecae2@github.com>
Message-ID: <cmT-0sTkGi1WfDYIg8rgC2TcQfAQHUeDENoTvR9aCKU=.ad0a2caa-8966-4faf-b84a-fd7dca5608cf@github.com>

On Fri, 16 May 2025 22:25:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Under the hood the Keyman input method appears as a US English keyboard layout. The characters attached to an NSEvent are always US English Roman even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct Hebrew or Dvorak character to insertText:replacementRange: instead.
>> 
>> This PR special-cases the Keyman layout, detecting it using the same method that AWT does. When Keyman is active Glass records the insertText: character and uses that when sending out KeyEvents.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second try at making Keyman work to some extent

Requesting review from @sgschantz (Keyman lead for macOS)

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

PR Comment: https://git.openjdk.org/jfx/pull/1805#issuecomment-2891781681

From arapte at openjdk.org  Tue May 20 07:55:02 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 May 2025 07:55:02 GMT
Subject: RFR: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <p7aMLqnRy5i_r6QUQ5VWAn6TDpqC9vmzoobedmQJ0BI=.95434dc8-694e-4bef-8160-850c25702fc3@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

lgtm

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1803#pullrequestreview-2853084469

From peterhull90 at gmail.com  Tue May 20 08:02:39 2025
From: peterhull90 at gmail.com (Peter Hull)
Date: Tue, 20 May 2025 09:02:39 +0100
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <CAK9Gx1ebKLBtEqzbmbLrwSZyNaQNKHMv5tueysGYLHXzUC=r7g@mail.gmail.com>

On Mon, 19 May 2025 at 17:14, Kevin Rushforth <kcr at openjdk.org> wrote:
>
> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.

Related to this, on the wiki it says that Cygwin is needed
(https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows)
but I tried without it and it seemed to build OK. Is Cygwin still a
requirement? I didn't attempt to build WebKit or the media.
Thanks
Peter

From arapte at openjdk.org  Tue May 20 09:37:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 May 2025 09:37:57 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <rB3h0-sPbAPDljIAaN8AmL-wVLxZ2GT4Rls2JyplCe8=.c08b89bd-2484-4b66-b047-dbcf038b65e8@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
 <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
 <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>
 <rB3h0-sPbAPDljIAaN8AmL-wVLxZ2GT4Rls
 2JyplCe8=.c08b89bd-2484-4b66-b047-dbcf038b65e8@github.com>
Message-ID: <y0nso0eNWA4nUU8il3KFbNdXT3--Q4tx89N6b1CG5Qg=.dcf96afa-4358-4ea5-a05b-19af7c202594@github.com>

On Thu, 15 May 2025 11:49:45 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>>> This would perform a layout of all cells, re-layout of previous cells and layout of next cells. but, layout of next cells is performed again as continuation layout of TreeView. A solution would be to break the loop when `cell` is current cell being layouted, so that at least the layout of next cells is not performed twice.
>> 
>> Would it be possible to avoid re-layout of the cells that are after the Cell with a disclosureNode ?
>
>> Would it be possible to avoid re-layout of the cells that are after the Cell with a disclosureNode ?
> 
> This is actually what is happening, when we scroll down and find a TreeCell that has a disclosure node this is when the condition `disclosureWidth > defaultDisclosureWidth` is true and we do a re-layout of the visible previous cells before the disclosure node and the new value is saved in the `maxDisclosureWidthMap` so the cells that are layouted after the disclosure node when scrolling are using the new value of `defaultDisclosureWidth`.

Yes, the cells after disclosure node use the new `defaultDisclosureWidth`. But their layout happens twice using the new `defaultDisclosureWidth`.

**First time**: The loop `for (IndexedCell cell : flow.cells) {` initiates the layout of all the cells, including the cells that are after the disclosure node.

**Second time**: and layout of those after cells happens again as part of ongoing layout of `TreeView` from this method `Parent.layout()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2097495175

From nlisker at gmail.com  Tue May 20 11:09:50 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 20 May 2025 12:09:50 +0100
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <CAK9Gx1ebKLBtEqzbmbLrwSZyNaQNKHMv5tueysGYLHXzUC=r7g@mail.gmail.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
 <CAK9Gx1ebKLBtEqzbmbLrwSZyNaQNKHMv5tueysGYLHXzUC=r7g@mail.gmail.com>
Message-ID: <CA+0ynh_zF1Mzpe7Dh2rqJTcRxYj9haUxn4=4uVzhJ6p0xAGZ=w@mail.gmail.com>

The instructions could be outdated. They need another pass in any case.

On Tue, May 20, 2025, 09:03 Peter Hull <peterhull90 at gmail.com> wrote:

> On Mon, 19 May 2025 at 17:14, Kevin Rushforth <kcr at openjdk.org> wrote:
> >
> > This PR updates the compiler on Windows to Visual Studio 2022 17.13.2
> (from 17.6.5) to match JDK 25.
>
> Related to this, on the wiki it says that Cygwin is needed
> (
> https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows
> )
> but I tried without it and it seemed to build OK. Is Cygwin still a
> requirement? I didn't attempt to build WebKit or the media.
> Thanks
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250520/3ffffd7b/attachment.htm>

From arapte at openjdk.org  Tue May 20 11:21:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 May 2025 11:21:57 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <cCSKb1yLCL7zphC6jcggrGHGCySN3_me8V5YE2ftomg=.c8c0fbbb-a4fb-477e-83af-290ef8ec16d3@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2853771698

From arapte at openjdk.org  Tue May 20 11:35:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 May 2025 11:35:57 GMT
Subject: RFR: 8355740: Update to Xcode 15.4 on macOS
In-Reply-To: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
References: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
Message-ID: <uXgLmuJt3FQdrxkQh5tY20ij8lFdR3V5abJFY0Q5fow=.5159500f-7a4d-4440-a195-55f853934320@github.com>

On Mon, 28 Apr 2025 18:41:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on macOS to Xcode 15.4 (from 14.3.1) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. No issues were found.
> 
> NOTE: Xcode 15.4 requires macOS 14 Sonoma to build (although it is known to build on macOS 13, which might be useful for developer builds). The generated JavaFX code will run on older versions of macOS.

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1798#pullrequestreview-2853807641

From gpattnaik at openjdk.org  Tue May 20 13:01:57 2025
From: gpattnaik at openjdk.org (Gopal Pattnaik)
Date: Tue, 20 May 2025 13:01:57 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <aTyC-vSTAdog0UaLEvW6FsVbIfj-GRS2JRC76_1IGXM=.f112a4e2-5fa7-4a4a-80f8-abe4381636df@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

/Confidential

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

PR Comment: https://git.openjdk.org/jfx/pull/1808#issuecomment-2894314495

From andy.goryachev at oracle.com  Tue May 20 14:46:45 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 20 May 2025 14:46:45 +0000
Subject: Let's discuss JDK-8338952
In-Reply-To: <b6431603-da1d-4210-8944-7317aaeb3e33@gmail.com>
References: <206c03a4-be9b-4e1d-ad73-5f4d193dc4c8@gmail.com>
 <CY8PR10MB7265AF87360AE4754C57D709E59CA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <b6431603-da1d-4210-8944-7317aaeb3e33@gmail.com>
Message-ID: <CY8PR10MB7265DFFCF6753F6AA2DA84FEE59FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Redundant?  Not really: to get the cell value from an item, one needs a pointer to the column.  Since the existing machinery already computes the value, we just pass it along with (what is missing now) a pointer to the item.  I think it's more "convenient", and one could possibly reuse the sort policy for multiple columns.

I don't know whether the column pointer needs to be passed - probably not, but perhaps I don't see scenarios where it might be needed, and it makes the policy more complicated since we now have to have separate policies for TableView and TreeTableView.

Example:

public interface SortPolicy<ITEM,VALUE> {
    public int compare(Tree/TableColumn column, ITEM itemA, VALUE valueA, ITEM itemB, VALUE valueB);
}

What do everyone think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, May 19, 2025 at 17:21
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Let's discuss JDK-8338952
Andy, I think this is a good solution because it provides everything needed for sorting.
Moreover, it complies with the generics of TableColumn.

For example,

var column = new TableColumn<Person, String>("First Name");
SortPolicy<Person, String> sortPolicy = ...
column.setSortPolicy(sortPolicy);

But don't you think the VALUE parameters are redundant since they can be obtained directly from ITEM?

Best regards, Pavel
On 5/19/25 22:28, Andy Goryachev wrote:
One possible solution would be to deprecate the comparator property (not for removal, keep it for backward compatibility), and add a new property 'sortPolicy' which will use an interface that can be evolved, as opposed to a naive callback.

public interface SortPolicy<ITEM,VALUE> {
    public int compare(ITEM itemA, VALUE valueA, ITEM itemB, VALUE valueB);
}

when set, the new property will override the comparator property.

What do you think?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, May 19, 2025 at 00:59
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Let's discuss JDK-8338952
About six months ago, I opened JDK-8338952 with a proposal to add an item comparator to (Tree)TableView.

The reason for this issue is that when using non-standard sorting ? for example, when there is a "Total"
row in the table ? the standard API becomes insufficient. One has to reinvent the wheel, and the code
quickly becomes extremely messy. Given that tables are one of the core UI components, this becomes
a serious problem.

To address this, I proposed adding an item comparator, which I believe would be very simple to implement.
I suggest we at least discuss this issue so we can start moving toward a solution.

Best regards, Pavel

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

From zelmidaoui at openjdk.org  Tue May 20 15:53:53 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 20 May 2025 15:53:53 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v6]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Avoid re-layout items twice after disclosure node width value updated

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/d0c46b14..63691364

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

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

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

From arapte at openjdk.org  Tue May 20 17:02:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 May 2025 17:02:58 GMT
Subject: RFR: 8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible
 [v2]
In-Reply-To: <U08OQWlgiM2ROkXqhh5qvrZJbr3IZhWui6IPzNKpZws=.d0e05570-a689-4a7f-a910-904d4a9ba155@github.com>
References: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
 <U08OQWlgiM2ROkXqhh5qvrZJbr3IZhWui6IPzNKpZws=.d0e05570-a689-4a7f-a910-904d4a9ba155@github.com>
Message-ID: <n3TT9xxM4he4B1k5JDbPyg9vx-Dq1k5HRqUZmzXZC6Q=.10fffa01-da8d-449d-af9f-5707dadad704@github.com>

On Thu, 8 May 2025 17:47:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed an NPE that should only happen in a headless test environment.
>> 
>> This is a follow-up for https://github.com/openjdk/jfx/pull/1677
>
> 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 remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
>  - on windows
>  - Merge remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
>  - npe

LGTM, seems safe to proceed with single review.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1793#pullrequestreview-2854967346

From angorya at openjdk.org  Tue May 20 17:20:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 May 2025 17:20:09 GMT
Subject: RFR: 8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible
 [v2]
In-Reply-To: <n3TT9xxM4he4B1k5JDbPyg9vx-Dq1k5HRqUZmzXZC6Q=.10fffa01-da8d-449d-af9f-5707dadad704@github.com>
References: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
 <U08OQWlgiM2ROkXqhh5qvrZJbr3IZhWui6IPzNKpZws=.d0e05570-a689-4a7f-a910-904d4a9ba155@github.com>
 <n3TT9xxM4he4B1k5JDbPyg9vx-Dq1k5HRqUZmzXZC6Q=.10fffa01-da8d-449d-af9f-5707dadad704@github.com>
Message-ID: <FBRoIBY-x2oL20KW1PBGR7sOnZBnV8uhmgXhNe23qh4=.f4a6df4a-4e7e-48b7-97d7-df6c2232fed9@github.com>

On Tue, 20 May 2025 17:00:33 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> 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 remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
>>  - on windows
>>  - Merge remote-tracking branch 'origin/master' into 8355415.scroll.to.visible
>>  - npe
>
> LGTM, seems safe to proceed with single review.

thank you, @arapte !

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

PR Comment: https://git.openjdk.org/jfx/pull/1793#issuecomment-2895247609

From angorya at openjdk.org  Tue May 20 17:20:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 May 2025 17:20:11 GMT
Subject: Integrated: 8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible
In-Reply-To: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
References: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
Message-ID: <-gNenJi7o5HCS5LsvsoOePMDojr8i3-U9GNrJ678W68=.4bdbd804-5c35-44a4-9c36-7d697ce5fa40@github.com>

On Wed, 23 Apr 2025 22:05:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE that should only happen in a headless test environment.
> 
> This is a follow-up for https://github.com/openjdk/jfx/pull/1677

This pull request has now been integrated.

Changeset: 9ca61edb
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9ca61edb982420371c509f62042284e09917d31e
Stats:     30 lines in 2 files changed: 4 ins; 19 del; 7 mod

8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible

Reviewed-by: arapte

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

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

From mhanl at openjdk.org  Tue May 20 17:32:59 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 20 May 2025 17:32:59 GMT
Subject: Integrated: 8356690: Update JUnit to 5.12.2
In-Reply-To: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
References: <sSFMWGVzuuXJQz8wYpUqhcYg2_Pf682J2_9jmG9mgqM=.55d1fabc-bf81-48a0-97ea-70c3059f8191@github.com>
Message-ID: <8r-KjqVxT_xgSgP8oimsCfEDmv-vWMBU3u_zr4cftA8=.8efe2892-7d74-4cc4-aafd-3df6e2c9f54a@github.com>

On Sat, 10 May 2025 23:41:44 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR bumps the JUnit version to 5.12.2.
> Also removed 2 now unused variables since I phased out the JUnit Vintage Engine + Hamcrest.
> 
> Changelog: https://junit.org/junit5/docs/current/release-notes/index.html#release-notes-5.12.2
> The mentioned deprecations do not affect us.
> 
> Interesting new features:
> - Thread dumps on test timeouts
> - Parameterized test validation improvements
> - JRE-based conditions such as @EnabledOnJre and @DisabledForJreRange now support arbitrary Java versions

This pull request has now been integrated.

Changeset: a14c2b33
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a14c2b33085a82c1e94d0964b3f3123e0ed7e7d2
Stats:     44 lines in 2 files changed: 0 ins; 2 del; 42 mod

8356690: Update JUnit to 5.12.2

Reviewed-by: kcr, arapte

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

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

From angorya at openjdk.org  Tue May 20 17:56:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 May 2025 17:56:56 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <y0nso0eNWA4nUU8il3KFbNdXT3--Q4tx89N6b1CG5Qg=.dcf96afa-4358-4ea5-a05b-19af7c202594@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
 <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
 <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>
 <rB3h0-sPbAPDljIAaN8AmL-wVLxZ2GT4Rls
 2JyplCe8=.c08b89bd-2484-4b66-b047-dbcf038b65e8@github.com>
 <y0nso0eNWA4nUU8il3KFbNdXT3--Q4tx89N6b1CG5Qg=.dcf96afa-4358-4ea5-a05b-19af7c202594@github.com>
Message-ID: <JzutHTxaYV7kJUqDX6JeO7Z_OWa6cDUtnLwxZKSe4zw=.17febf87-d7c7-4c65-940d-bb9fa361730a@github.com>

On Tue, 20 May 2025 09:35:45 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>>> Would it be possible to avoid re-layout of the cells that are after the Cell with a disclosureNode ?
>> 
>> This is actually what is happening, when we scroll down and find a TreeCell that has a disclosure node this is when the condition `disclosureWidth > defaultDisclosureWidth` is true and we do a re-layout of the visible previous cells before the disclosure node and the new value is saved in the `maxDisclosureWidthMap` so the cells that are layouted after the disclosure node when scrolling are using the new value of `defaultDisclosureWidth`.
>
> Yes, the cells after disclosure node use the new `defaultDisclosureWidth`. But their layout happens twice using the new `defaultDisclosureWidth`.
> 
> **First time**: The loop `for (IndexedCell cell : flow.cells) {` initiates the layout of all the cells, including the cells that are after the disclosure node.
> 
> **Second time**: and layout of those after cells happens again as part of ongoing layout of `TreeView` from this method `Parent.layout()`

as long as both layouts happens within the same pulse, we should be ok.
I did not see any flicker with the last change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2098561451

From mstrauss at openjdk.org  Tue May 20 19:01:26 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 20 May 2025 19:01:26 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:

 - Merge branch 'master' into feature/extended-window
 - javadoc
 - Merge branch 'master' into feature/extended-window
 - reapply overlay CSS
 - Merge branch 'master' into feature/extended-window
 - simplify header area picking
 - Fix top resize border on Windows
 - Merge branch 'master' into feature/extended-window
 - doc change
 - add HeaderDragType
 - ... and 86 more: https://git.openjdk.org/jfx/compare/a14c2b33...dcbb68d0

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=74
  Stats: 6805 lines in 76 files changed: 6114 ins; 517 del; 174 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

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

From zelmidaoui at openjdk.org  Tue May 20 19:34:57 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 20 May 2025 19:34:57 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v5]
In-Reply-To: <JzutHTxaYV7kJUqDX6JeO7Z_OWa6cDUtnLwxZKSe4zw=.17febf87-d7c7-4c65-940d-bb9fa361730a@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <zQzEeShkpVEXQLCc48Ifi4Jy-6EtjOd1AWu8m2Czfxc=.a80336f5-6a60-4b5a-b070-9dc9fa47863f@github.com>
 <pZPKvmB46IRWRZK2Z0S8DPkNA1ryl0meI6LNE2akazM=.0b2c70eb-ab1d-42bc-a823-02e04f2f151d@github.com>
 <JPUVd-broSxoAc7eOYTdRp1ChvwJ4jh-jKJlma44I-A=.a6dae1fc-b151-4c74-ab9e-0536dd70a9a7@github.com>
 <i-z12-ym0VR59nv8-eweiRY_WXY9nTRFak6tS4Tj0CM=.17620a2d-295d-4fe4-bfce-515ce229e42f@github.com>
 <es2Lyq24P-FWGbHhYWPqTUG6eLI47XwnJhBx6Ney80I=.80a51d69-e23c-4bbb-beec-2f9e5915cb07@github.com>
 <2uzF8PXhpXRNb8-ESIlHZfLv-JjQlEjafHXLDO2bVTo=.17028c27-6711-4a49-9ab3-babf5f9bef18@github.com>
 <ABDl8ra3zYaeUOGLqu4vWhzBm9V81EFrfeSc9RKAdaw=.7fef3750-ebd7-462b-bdb2-a703374fd1b1@github.com>
 <v3GY-FsE6FCGpsd_AfcCgzQ3wJF7AYyTIr5kh1NL-U8=.0f908df7-2541-411d-b26c-77d372d69401@github.com>
 <XrHRAJRi51rq9j8-34qiFFfOlxGe9DUebNuCy6Nm3pM=.0afb0779-a5c5-4c3a-b4e4-2fd0868f5ccd@github.com>
 <rB3h0-sPbAPDljIAaN8AmL-wVLxZ2GT4Rls
 2JyplCe8=.c08b89bd-2484-4b66-b047-dbcf038b65e8@github.com>
 <y0nso0eNWA4nUU8il3KFbNdXT3--Q4tx89N6b1CG5Qg=.dcf96afa-4358-4ea5-a05b-19af7c202594@github.com>
 <JzutHTxaYV7kJUqDX6JeO7Z_OWa6cDUtnLwxZKSe4zw=.17febf87-d7c7-4c65-940d-bb9fa361730a@github.com>
Message-ID: <cS3yCZo0moU54qDgVGys9t97q3oGrig1sGgd2M8XT6g=.00a7b39d-9941-44a3-992f-e534441ffc79@github.com>

On Tue, 20 May 2025 17:53:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, the cells after disclosure node use the new `defaultDisclosureWidth`. But their layout happens twice using the new `defaultDisclosureWidth`.
>> 
>> **First time**: The loop `for (IndexedCell cell : flow.cells) {` initiates the layout of all the cells, including the cells that are after the disclosure node.
>> 
>> **Second time**: and layout of those after cells happens again as part of ongoing layout of `TreeView` from this method `Parent.layout()`
>
> as long as both layouts happens within the same pulse, we should be ok.
> I did not see any flicker with the last change.

Yes,
I did limit the re-layout in my fix to happen only for the cells before the disclosure node cell.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2098719206

From angorya at openjdk.org  Tue May 20 19:37:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 May 2025 19:37:58 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v6]
In-Reply-To: <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>
Message-ID: <4SCmF9--qGJBOeYqpsRzaorI-CnG4QcN7XwbNJWH1-4=.60d516ad-27b1-4fab-874c-84f51f1fdc88@github.com>

On Tue, 20 May 2025 15:53:53 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid re-layout items twice after disclosure node width value updated

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1715#pullrequestreview-2855372143

From arapte at openjdk.org  Wed May 21 05:11:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 21 May 2025 05:11:58 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v6]
In-Reply-To: <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>
Message-ID: <FdDtUNJXWQQPEOhXM0cVEkz8X9ia-lwNi2iTqBQbgkI=.40aa8d6b-6b8b-4d79-a92a-3bb626b858d2@github.com>

On Tue, 20 May 2025 15:53:53 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid re-layout items twice after disclosure node width value updated

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 232:

> 230:                                 cell.requestLayout();
> 231:                                 cell.layout();
> 232:                             }

Just a minor change please.
The for loop could break when `cell.getIndex() >= indexWithDisclosureNode`, so that we avoid looping through the cells that are after disclosureNode.


for (IndexedCell cell : flow.cells) {
    if (cell != null) {
        if (cell.getIndex() >= indexWithDisclosureNode) {
            break;
        } else if (!cell.isEmpty()) {
            cell.requestLayout();
            cell.layout();
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2099356105

From sykora at openjdk.org  Wed May 21 07:51:04 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 21 May 2025 07:51:04 GMT
Subject: RFR: 8355740: Update to Xcode 15.4 on macOS
In-Reply-To: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
References: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
Message-ID: <ekwHaKyK5z6oRSvC4ee3ZYOdCF0WlL9U2jG1JSY1y4Y=.ad71a9fe-415b-47ee-8a6c-aa47072ebb11@github.com>

On Mon, 28 Apr 2025 18:41:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on macOS to Xcode 15.4 (from 14.3.1) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. No issues were found.
> 
> NOTE: Xcode 15.4 requires macOS 14 Sonoma to build (although it is known to build on macOS 13, which might be useful for developer builds). The generated JavaFX code will run on older versions of macOS.

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1798#pullrequestreview-2856671077

From zelmidaoui at openjdk.org  Wed May 21 10:22:10 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 21 May 2025 10:22:10 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v7]
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1715/files
  - new: https://git.openjdk.org/jfx/pull/1715/files/63691364..26b6e388

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

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

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

From zelmidaoui at openjdk.org  Wed May 21 10:22:10 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 21 May 2025 10:22:10 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v6]
In-Reply-To: <FdDtUNJXWQQPEOhXM0cVEkz8X9ia-lwNi2iTqBQbgkI=.40aa8d6b-6b8b-4d79-a92a-3bb626b858d2@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <SQCA8Fnrch7IGLj0NJc4E9TA4nkuZOzh2xI5P1mOX7o=.8ee5107a-4841-4f05-8034-7b7db7149fc8@github.com>
 <FdDtUNJXWQQPEOhXM0cVEkz8X9ia-lwNi2iTqBQbgkI=.40aa8d6b-6b8b-4d79-a92a-3bb626b858d2@github.com>
Message-ID: <vHMn44RDmYQGhRIRwL2EAzkTPRMGY7WKaTUEfP2sEhw=.54266be7-a37e-4123-8406-e6223d515e86@github.com>

On Wed, 21 May 2025 05:09:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid re-layout items twice after disclosure node width value updated
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 232:
> 
>> 230:                                 cell.requestLayout();
>> 231:                                 cell.layout();
>> 232:                             }
> 
> Just a minor change please.
> The for loop could break when `cell.getIndex() >= indexWithDisclosureNode`, so that we avoid looping through the cells that are after disclosureNode.
> 
> 
> for (IndexedCell cell : flow.cells) {
>     if (cell != null) {
>         if (cell.getIndex() >= indexWithDisclosureNode) {
>             break;
>         } else if (!cell.isEmpty()) {
>             cell.requestLayout();
>             cell.layout();
>         }
>     }
> }

Thanks for the suggestion,
I have pushed new changes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1715#discussion_r2099917922

From arapte at openjdk.org  Wed May 21 14:25:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 21 May 2025 14:25:00 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v7]
In-Reply-To: <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
Message-ID: <ClcLNtPD1Tp0miMU-DIJ8694WCQN6CZRExKi35OsMdk=.33338bac-047c-4f98-9112-e437d8636be6@github.com>

On Wed, 21 May 2025 10:22:10 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1715#pullrequestreview-2857943251

From kcr at openjdk.org  Wed May 21 14:42:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 May 2025 14:42:59 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <MySbRpB0fw2jW_2TWhhA79f6m9NKObU-pPEZB6dASLo=.f4bb20b1-c991-4352-bf5c-273a405fede1@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

Looks good. I can login to microsoft.com with this fix (I was unable to before the fix).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1808#pullrequestreview-2858008644

From angorya at openjdk.org  Wed May 21 14:49:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 21 May 2025 14:49:04 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v7]
In-Reply-To: <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
Message-ID: <j5FnsCFhdEcyPxZMJivb5cIynijkGitA4WSP7LRerfA=.be1b034e-7497-427b-87cd-f4e55324d840@github.com>

On Wed, 21 May 2025 10:22:10 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1715#pullrequestreview-2858015681

From zelmidaoui at openjdk.org  Wed May 21 14:49:05 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 21 May 2025 14:49:05 GMT
Subject: RFR: 8340344: The first item in TreeView is not aligned in the
 beginning [v7]
In-Reply-To: <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
 <_gXmlabmwlwfLImzz5EsIhX3tBP-8c3_zDt_lVsIQ2M=.ae1a22e2-23dd-4b1e-887b-456272e9555d@github.com>
Message-ID: <CkbFE40eYWOQWIIqM7q5o-qF5EOCfEEFsYcT_l7TEws=.a992de3e-b15f-471e-9910-4591cda46229@github.com>

On Wed, 21 May 2025 10:22:10 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes

Thanks for reviews!

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

PR Comment: https://git.openjdk.org/jfx/pull/1715#issuecomment-2898225033

From zelmidaoui at openjdk.org  Wed May 21 14:49:05 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 21 May 2025 14:49:05 GMT
Subject: Integrated: 8340344: The first item in TreeView is not aligned in the
 beginning
In-Reply-To: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
References: <LNlj_dW-aVRmIhjNzzqTXY1HivHtOYMJ69Q1Zqam040=.4c8c96ff-b655-41eb-9250-a82eb25e4687@github.com>
Message-ID: <1SZ0tgIwu4NV5QZxxC55Ir3ni_K76qs_7sB5B-KCTRk=.e31432bf-6e78-4466-a768-95e06005a773@github.com>

On Wed, 19 Feb 2025 16:45:54 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurred because items preceding an item with children (items with a disclosure node) had different widths, which led to misalignment. This can be fixed by requesting a cell relayout whenever the disclosure node's width changes.

This pull request has now been integrated.

Changeset: d5f569cf
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d5f569cf29d309cd55d5c720d6539192dfa58e51
Stats:     74 lines in 2 files changed: 74 ins; 0 del; 0 mod

8340344: The first item in TreeView is not aligned in the beginning

Reviewed-by: angorya, arapte

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

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

From angorya at openjdk.org  Wed May 21 20:46:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 21 May 2025 20:46:32 GMT
Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes
Message-ID: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com>

Fixing a bug that breaks proper serialization of character attributes.

This, unfortunately, makes a breaking change in the RichTextArea native format [0].

## References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea_DataFormat_V2.md

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

Commit messages:
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser
 - test
 - tests
 - fixed attribute serialization

Changes: https://git.openjdk.org/jfx/pull/1813/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1813&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357393
  Stats: 188 lines in 6 files changed: 96 ins; 41 del; 51 mod
  Patch: https://git.openjdk.org/jfx/pull/1813.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1813/head:pull/1813

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

From kcr at openjdk.org  Wed May 21 21:27:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 May 2025 21:27:03 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v26]
In-Reply-To: <u_1-Y2CrdRLuccSNdepq4h600wUmm6MEPGUOZ6d1kR8=.a81b83e0-e91a-4cd1-be38-be12207519c9@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <u_1-Y2CrdRLuccSNdepq4h600wUmm6MEPGUOZ6d1kR8=.a81b83e0-e91a-4cd1-be38-be12207519c9@github.com>
Message-ID: <BYs67PewG8N7xR78mSvDT8exsZz5gbjgejqWt3KRXZM=.6201e89f-fbc5-4cd3-b6b3-5d0eab022887@github.com>

On Fri, 2 May 2025 17:42:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - sealed
>  - indent
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - twice
>  - tests
>  - review comments
>  - ... and 43 more: https://git.openjdk.org/jfx/compare/498b7e4c...982ef1f7

The changes to the API look good. I left a few wording suggestions. Once those are resolved, update the CSR.

I see that this PR lists [JDK-8341671](https://bugs.openjdk.org/browse/JDK-8341671) and [JDK-8341672](https://bugs.openjdk.org/browse/JDK-8341672) as additional issues solved. They are included as part of the text LayoutInfo, so it would be better to close them as duplicates and remove them from this PR (using `/issue remove`).

modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 32:

> 30: 
> 31: /**
> 32:  * Provides a snapshot of the text layout geometry in a {@code Text} or a {@code TextFlow} node,

I might either remove the word "Provides" or else replace it with "Holds".

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 2097:

> 2095:      * this lightweight object remains valid until the next layout cycle.
> 2096:      *
> 2097:      * @return the layout information

maybe "a copy of the ..."?

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 719:

> 717: 
> 718:     /**
> 719:      * Returns the object which provides a snapshot of the text layout geometry for this node.

Same comment as for Text::getLayoutInfo

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

PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2859084182
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101152942
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101145917
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101146652

From kcr at openjdk.org  Wed May 21 21:27:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 May 2025 21:27:04 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v25]
In-Reply-To: <mal__UlcKUlV8D6uJ5sT-npZbmG7QdqHiFrXeiHbSLk=.3d22661f-9082-4bcd-9ca0-715876d821df@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <FSGxqaTjt6T7_N3uDzucGJWZjl2lBLI7FM5oSqxEXj0=.56de0fc6-9dce-4944-9fae-cc29f8cd674f@github.com>
 <frwnLT598X8oIKApZB733kmzrnayiQiksObGBxsPJug=.16b8a34e-12ae-4b70-9df9-e2bface45e23@github.com>
 <mal__UlcKUlV8D6uJ5sT-npZbmG7QdqHiFrXeiHbSLk=.3d22661f-9082-4bcd-9ca0-715876d821df@github.com>
Message-ID: <vYWbkjTgpdCTYJ2sst-hUsyxtlE9FLvfCl5AWuju27A=.d19d0510-a9b1-41a1-a0b9-f84d1f4c9e67@github.com>

On Fri, 2 May 2025 16:57:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 2100:
>> 
>>> 2098:      * While there is no general guarantee that successive invocations of this method return the same instance,
>>> 2099:      * it is safe to either cache this object or call this method each time, since the information obtained from
>>> 2100:      * this lightweight object remains valid until the next layout cycle.
>> 
>> I'm trying to parse this to get a better idea of the model. If this really is a "view" into the current layout information for the text node, then the information returned by the getters in the TextLayout will change over time, right?
>> 
>> This is true whether you call the TextLayoutInfo once on a given text node and reuse it for the life of that text node or whether you call `Text::getLayoutInfo` every time you want to use it. I guess that's what you are trying to say. If so, is there a need to mention that there is no guarantee that it will return the same instance?
>
> good comment.  how does this sound:
> 
> Returns the object which provides a snapshot of the text layout geometry for this node.

Oh, so it _isn't_ a view but a copy. I think what you changed it to is closer. The "object which provides a snapshot" is a little misleading, though. It is this method that _provides_ the snapshot. The returned TextLayout object _is_ the snapshot. Maybe something like this?


* Returns a copy of the of the text layout geometry for this node. This copy is a snapshot
* of the text layout at the time the method is called.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101142533

From angorya at openjdk.org  Wed May 21 22:52:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 21 May 2025 22:52:36 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v27]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

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

 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - sealed
 - indent
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - twice
 - ... and 45 more: https://git.openjdk.org/jfx/compare/d5f569cf...0ac75dae

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=26
  Stats: 1522 lines in 13 files changed: 1463 ins; 18 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

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

From mstrauss at openjdk.org  Wed May 21 23:52:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 21 May 2025 23:52:00 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
Message-ID: <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>

On Mon, 10 Mar 2025 16:08:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 256:
>> 
>>> 254:      * @return the caret geometry
>>> 255:      */
>>> 256:     public float[] getCaretGeometry(int offset, boolean leading);
>> 
>> Does this method throw any exceptions? If so, please specify.
>
> This method does not throw any exceptions, so none are specified.

Instead of returning `float[]` here, this would be a good candidate to return a discriminated union instead, something like:

sealed interface CaretGeometry {
    record Single(float x, float y, float height) implements CaretGeometry {}
    record Split(float x1, float x2, float y, float height) implements CaretGeometry {}
}


This has two advantages:
1. It's more expressive, as you don't need to look up what the array values represent.
2. Instead of disciminating between the two cases by inspecting the array length as you do in `PrismLayoutInfo::caretInfoAt`:

   ```java
   Rectangle2D[] parts;
   if (c.length == 3) {
       ..
       parts = ...
   } else {
       ...
       parts = ...
   }
   ```
   ...you can use an exhaustive switch expression instead:
   ```
   Rectangle2D[] parts = switch (c) {
       case Single s -> new Rectangle2D[] {
           new Rectangle2D(s.x() + dx, s.y() + dy, 0, s.height())
       };
   
       case Split s -> new Rectangle2D[] {
           new Rectangle2D(...),
           new Rectangle2D(...)
       };
   };
   ```

   This is easier to read, and you'll get the compiler checks for free.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101366202

From kcr at openjdk.org  Thu May 22 00:13:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 May 2025 00:13:58 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v27]
In-Reply-To: <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>
Message-ID: <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>

On Wed, 21 May 2025 22:52:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - sealed
>  - indent
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - twice
>  - ... and 45 more: https://git.openjdk.org/jfx/compare/d5f569cf...0ac75dae

Updated API looks good. I left a comment on the CSR.

I left a comment on one other naming / semantic issue that I just noticed.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1123:

> 1121:      * @since 25
> 1122:      */
> 1123:     public final PathElement[] getStrikeThroughShape(int start, int end) {

I just noticed that this is named `getStrikeThroughShape` rather than `strikeThroughShape`. The latter would match the similar `rangeShape`, `caretShape`, and `underlineShape` methods. We had discussed that you might propose to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) by deprecating `rangeShape` and `underlineShape` and adding new `getRangeShape` and `getUnderlineShape` methods (although that might be problematic given the `caretShape` property, which necessarily already has a no-arg `getCaretShape()` method).

Did you name this method `getStrikeThroughShape` with the intention that it would have the fixed semantics of applying the insets from its inception? If so, then I recommend documenting that fact in this method.

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

PR Review: https://git.openjdk.org/jfx/pull/1596#pullrequestreview-2859420757
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2101379499

From kizune at openjdk.org  Thu May 22 05:43:59 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 22 May 2025 05:43:59 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v3]
In-Reply-To: <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
Message-ID: <1RhfGn2lO-mw_e0UoU5FUd_lEtvAtLJ5kDI1V2c3ST8=.96615afc-5854-4a0b-a090-1c4d3343ab6c@github.com>

On Sat, 17 May 2025 12:24:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove system property

Looks reasonable although not having a way to override a threshold is strange. OTOH 100 is a generous enough for the application.

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

Marked as reviewed by kizune (Author).

PR Review: https://git.openjdk.org/jfx/pull/1811#pullrequestreview-2859849186

From jvos at openjdk.org  Thu May 22 09:43:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 09:43:47 GMT
Subject: [jfx21u] RFR: 8352162: Update libxml2 to 2.13.8
Message-ID: <jOC8xBTxluVxPZeDwZXg224w4xuP6FjAfmGes-K2zh0=.ab2e51d8-bd72-4efc-8987-e5632ec3decf@github.com>

Hi all,

This pull request contains a backport of commit 4df23263 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 4df2326391b3528c48a4594ec9f3bb6fdde9a437

Changes: https://git.openjdk.org/jfx21u/pull/97/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=97&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352162
  Stats: 102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod
  Patch: https://git.openjdk.org/jfx21u/pull/97.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/97/head:pull/97

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

From jvos at openjdk.org  Thu May 22 09:52:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 09:52:06 GMT
Subject: [jfx21u] Integrated: 8352162: Update libxml2 to 2.13.8
In-Reply-To: <jOC8xBTxluVxPZeDwZXg224w4xuP6FjAfmGes-K2zh0=.ab2e51d8-bd72-4efc-8987-e5632ec3decf@github.com>
References: <jOC8xBTxluVxPZeDwZXg224w4xuP6FjAfmGes-K2zh0=.ab2e51d8-bd72-4efc-8987-e5632ec3decf@github.com>
Message-ID: <z7sp_BQI509NcxwvQSMZhEl93La6SCOwQjDSJ9wwa64=.4e88807b-30d8-44cd-98a2-34a0a2553c1a@github.com>

On Thu, 22 May 2025 09:38:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 4df23263 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d5d22b57
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/d5d22b574dcc124af4935aea6462ff8db58aa2fd
Stats:     102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod

8352162: Update libxml2 to 2.13.8
8352164: Update libxslt to 1.1.43

Backport-of: 4df2326391b3528c48a4594ec9f3bb6fdde9a437

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

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

From jvos at openjdk.org  Thu May 22 09:55:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 09:55:19 GMT
Subject: [jfx17u] RFR: 8352162: Update libxml2 to 2.13.8
Message-ID: <1SETXoJnCC78vx9g_SPW9OkM90G7AOui3gB4xaOaj70=.1c8efcbd-f9be-46fb-b6f5-41d492d6e7ae@github.com>

Hi all,

This pull request contains a backport of commit 4df23263 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 4df2326391b3528c48a4594ec9f3bb6fdde9a437

Changes: https://git.openjdk.org/jfx17u/pull/234/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352162
  Stats: 102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod
  Patch: https://git.openjdk.org/jfx17u/pull/234.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/234/head:pull/234

PR: https://git.openjdk.org/jfx17u/pull/234

From jvos at openjdk.org  Thu May 22 10:08:57 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 10:08:57 GMT
Subject: [jfx17u] Integrated: 8352162: Update libxml2 to 2.13.8
In-Reply-To: <1SETXoJnCC78vx9g_SPW9OkM90G7AOui3gB4xaOaj70=.1c8efcbd-f9be-46fb-b6f5-41d492d6e7ae@github.com>
References: <1SETXoJnCC78vx9g_SPW9OkM90G7AOui3gB4xaOaj70=.1c8efcbd-f9be-46fb-b6f5-41d492d6e7ae@github.com>
Message-ID: <CFR-PNdI8wYOV_WL2eYfWmDh4kCuB-ZgfY5fsJbYZ8U=.984e1846-d330-42df-a782-34a998e6c7c9@github.com>

On Thu, 22 May 2025 09:46:37 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 4df23263 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 5ff37684
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/5ff37684d93aab20fb84d9c77c0bfe57c3254fd5
Stats:     102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod

8352162: Update libxml2 to 2.13.8
8352164: Update libxslt to 1.1.43

Backport-of: 4df2326391b3528c48a4594ec9f3bb6fdde9a437

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

PR: https://git.openjdk.org/jfx17u/pull/234

From jvos at openjdk.org  Thu May 22 10:21:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 10:21:08 GMT
Subject: [jfx21u] Integrated: 8354876: Update SQLite to 3.49.1
Message-ID: <L4vRGyhwQZxfiOjXfnKwaHFZmI30glKTUY7sHoD1bWA=.5aeffdc5-4d40-476a-9ee6-ea6a428da918@github.com>

Hi all,

This pull request contains a backport of commit 46b36fe4 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 46b36fe432aab81468df44344ab5e36aa31c5f47

Changes: https://git.openjdk.org/jfx21u/pull/98/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=98&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354876
  Stats: 13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod
  Patch: https://git.openjdk.org/jfx21u/pull/98.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/98/head:pull/98

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

From jvos at openjdk.org  Thu May 22 10:21:09 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 10:21:09 GMT
Subject: [jfx21u] Integrated: 8354876: Update SQLite to 3.49.1
In-Reply-To: <L4vRGyhwQZxfiOjXfnKwaHFZmI30glKTUY7sHoD1bWA=.5aeffdc5-4d40-476a-9ee6-ea6a428da918@github.com>
References: <L4vRGyhwQZxfiOjXfnKwaHFZmI30glKTUY7sHoD1bWA=.5aeffdc5-4d40-476a-9ee6-ea6a428da918@github.com>
Message-ID: <2bU0XWS2WwHbBTRQHQmOAA6-06FXT7_ZSYwdIyiIv8Y=.3577504c-9dee-4e5a-b940-7ae258257be2@github.com>

On Thu, 22 May 2025 10:13:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 46b36fe4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 87494a66
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/87494a6618bafaa30a278135798c5ba2294dca3d
Stats:     13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod

8354876: Update SQLite to 3.49.1

Backport-of: 46b36fe432aab81468df44344ab5e36aa31c5f47

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

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

From jvos at openjdk.org  Thu May 22 10:22:17 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 10:22:17 GMT
Subject: [jfx17u] Integrated: 8354876: Update SQLite to 3.49.1
Message-ID: <Wh2oSmzSvSKVn7hieP7fohXv5kseJl4TCBnEL7Vk6GI=.c64020f9-4feb-450b-ac22-61749dea78dc@github.com>

Hi all,

This pull request contains a backport of commit 46b36fe4 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 46b36fe432aab81468df44344ab5e36aa31c5f47

Changes: https://git.openjdk.org/jfx17u/pull/235/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354876
  Stats: 13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod
  Patch: https://git.openjdk.org/jfx17u/pull/235.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/235/head:pull/235

PR: https://git.openjdk.org/jfx17u/pull/235

From jvos at openjdk.org  Thu May 22 10:22:17 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 May 2025 10:22:17 GMT
Subject: [jfx17u] Integrated: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Wh2oSmzSvSKVn7hieP7fohXv5kseJl4TCBnEL7Vk6GI=.c64020f9-4feb-450b-ac22-61749dea78dc@github.com>
References: <Wh2oSmzSvSKVn7hieP7fohXv5kseJl4TCBnEL7Vk6GI=.c64020f9-4feb-450b-ac22-61749dea78dc@github.com>
Message-ID: <uKA1vF9ZSbljJakCXDqyhLVaP66NjsSPOTF0YPvUHjg=.a62e1101-639c-4d12-bd4d-61c51cc5e6c6@github.com>

On Thu, 22 May 2025 10:12:04 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 46b36fe4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 23 Apr 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a64ae058
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/a64ae05884983d0d3d4d06f76ba24efe9b8eaa42
Stats:     13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod

8354876: Update SQLite to 3.49.1

Backport-of: 46b36fe432aab81468df44344ab5e36aa31c5f47

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

PR: https://git.openjdk.org/jfx17u/pull/235

From mstrauss at openjdk.org  Thu May 22 10:25:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 22 May 2025 10:25:01 GMT
Subject: Integrated: 8357157: Exception thrown from AnimationTimer freezes
 application
In-Reply-To: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
Message-ID: <q1sDI4Apuu7IabaehlmXUdl95NQbyLevHwNeEyTl5kA=.fa4ce850-3c33-46af-80ae-88d91d3d5d38@github.com>

On Fri, 16 May 2025 14:38:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
> 
> The following program demonstrates the defect:
> 
> 
> public class FailingAnimationTimer extends Application {
>     @Override
>     public void start(Stage stage) throws Exception {
>         var button = new Button("start timer");
>         button.setOnAction(_ -> {
>             var timer = new AnimationTimer() {
>                 @Override
>                 public void handle(long l) {
>                     throw new RuntimeException("foo");
>                 }
>             };
> 
>             timer.start();
>         });
> 
>         var root = new HBox();
>         root.getChildren().add(new TextField("test"));
>         root.getChildren().add(button);
>         stage.setScene(new Scene(root));
>         stage.show();
>     }
> }
> 
> 
> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
> 
> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
> 
> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`

This pull request has now been integrated.

Changeset: 192b8613
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/192b86137d9a29c5c420434f8021f8dabd21dccf
Stats:     229 lines in 2 files changed: 205 ins; 4 del; 20 mod

8357157: Exception thrown from AnimationTimer freezes application

Reviewed-by: angorya, kizune

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

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

From kcr at openjdk.org  Thu May 22 12:19:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 May 2025 12:19:58 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v5]
In-Reply-To: <db3bg2T3lewGUIBBo4e3HzCFISdhp5YW8yqoBrSPQ2U=.32e66ba0-01a9-4a3f-a34f-837f924beba2@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <db3bg2T3lewGUIBBo4e3HzCFISdhp5YW8yqoBrSPQ2U=.32e66ba0-01a9-4a3f-a34f-837f924beba2@github.com>
Message-ID: <3Ppfe0ccEXxxjpRUp-rmtoLCc4QFoXuLZEriL5rpOLI=.8c3b3fbe-03fd-407a-a508-57c65c940a8f@github.com>

On Sat, 10 May 2025 22:55:12 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR enables `javafx.swt` tests for:
>> - Windows
>> 
>> Disabled on:
>> - Linux, since some distros seems to have problems -> https://bugs.openjdk.org/browse/JDK-8356688
>> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread` -> https://bugs.openjdk.org/browse/JDK-8356687
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link JDK tickets

Looks good. One reviewer should be enough given the scope of this test-only change.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1783#pullrequestreview-2860999782

From pavelturk2000 at gmail.com  Thu May 22 12:29:35 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 22 May 2025 15:29:35 +0300
Subject: CodeArea: request to raise priority of JDK-8357405 (text length
 metrics for ContentChange)
Message-ID: <8d32334e-cb6e-4d62-9138-a917a8549ecc@gmail.com>

I'd like to kindly ask for consideration in raising the priority of JDK-8357405 about adding text length
metrics to ContentChange for removed/inserted text for CodeArea.

The reason for this request is that accurate and reliable information about text changes is essential
when integrating CodeArea with code processing libraries. Currently, CodeArea does not provide
such information.

As a result, CodeArea can only be reliably used in read-only mode at the moment ? which severely
limits its applicability in real-world applications.

Best regards, Pavel

From duke at openjdk.org  Thu May 22 12:35:02 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 12:35:02 GMT
Subject: RFR: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <yDny2sDUA0WwWcX_r75HhVkzIya9T30KCfpqcZuHY8o=.9a2eb97f-920b-4a56-8034-9f1fd7ab51fe@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

@Gopalora 
Your change (at version 6ed58903ddd6b420f8e0c94b7bed5e5bc42abd2b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1808#issuecomment-2901062183

From gpattnaik at openjdk.org  Thu May 22 12:52:57 2025
From: gpattnaik at openjdk.org (Gopal Pattnaik)
Date: Thu, 22 May 2025 12:52:57 GMT
Subject: Integrated: 8354940: Fail to sign in to Microsoft sites with WebView
In-Reply-To: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
References: <YEkX2v1zGEGUVCEo3DBWrTjQUp5W81Jxt6slU_0ENTg=.f77bfa25-c7b2-4c8e-b0d0-42b3b0a04127@github.com>
Message-ID: <sNMFzqsMvT6h6nkYwxBX9nwY1pIljDnkoriOcgW6Es8=.9860edc3-c33b-4dfd-b2ca-69fa0dc2c648@github.com>

On Thu, 15 May 2025 09:26:42 GMT, Gopal Pattnaik <gpattnaik at openjdk.org> wrote:

> On loading of the reported URL, it looks like a browser version check is made (like Safari version, Chrome version etc). At present the browser version is not part of the user agent string we are using for JavaFX Webview
> 
> Solution:
> Added a version string in the user agent similar to Safari.
> 
> Verification:
> The test program attached to the JBS passes with this change.

This pull request has now been integrated.

Changeset: ac12979b
Author:    Gopal Pattnaik <gpattnaik at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ac12979bc3100cf4f263a38669a59dac2b71fdce
Stats:     12 lines in 3 files changed: 12 ins; 0 del; 0 mod

8354940: Fail to sign in to Microsoft sites with WebView

Reviewed-by: kcr, jbhaskar

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

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

From kcr at openjdk.org  Thu May 22 14:33:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 May 2025 14:33:02 GMT
Subject: Integrated: 8355740: Update to Xcode 15.4 on macOS
In-Reply-To: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
References: <qoG9guxvTmnK3JgtljlmgEuEmDhU7nM_X7fp38ntCv4=.3fa0ba0c-7601-4cd1-97e6-4128a37dd41a@github.com>
Message-ID: <4S6mP3ihm9E7HWOyTlwbmOQUBWCKW3Jn5QFVLD6QBEI=.a3750bf9-68e3-48db-ab56-077b8ae2bf94@github.com>

On Mon, 28 Apr 2025 18:41:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on macOS to Xcode 15.4 (from 14.3.1) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. No issues were found.
> 
> NOTE: Xcode 15.4 requires macOS 14 Sonoma to build (although it is known to build on macOS 13, which might be useful for developer builds). The generated JavaFX code will run on older versions of macOS.

This pull request has now been integrated.

Changeset: 59c2b759
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/59c2b7591bc959a5b8155a815dc918a89b79cc76
Stats:     8 lines in 3 files changed: 1 ins; 1 del; 6 mod

8355740: Update to Xcode 15.4 on macOS

Reviewed-by: arapte, sykora

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

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

From angorya at openjdk.org  Thu May 22 14:43:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 14:43:02 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
 <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>
Message-ID: <9riBy73SclQdKMRgGTuWVyuhoa9l7ZaYfXTzlR2g41w=.e3ef03bc-fdcf-48b5-b56b-3848f3e8cc2b@github.com>

On Wed, 21 May 2025 23:49:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This method does not throw any exceptions, so none are specified.
>
> Instead of returning `float[]` here, this would be a good candidate to return a discriminated union instead, something like:
> 
> sealed interface CaretGeometry {
>     record Single(float x, float y, float height) implements CaretGeometry {}
>     record Split(float x1, float x2, float y, float height) implements CaretGeometry {}
> }
> 
> 
> This has two advantages:
> 1. It's more expressive, as you don't need to look up what the array values represent.
> 2. Instead of disciminating between the two cases by inspecting the array length as you do in `PrismLayoutInfo::caretInfoAt`:
> 
>    ```java
>    Rectangle2D[] parts;
>    if (c.length == 3) {
>        ..
>        parts = ...
>    } else {
>        ...
>        parts = ...
>    }
>    ```
>    ...you can use an exhaustive switch expression instead:
>    ```
>    Rectangle2D[] parts = switch (c) {
>        case Single s -> new Rectangle2D[] {
>            new Rectangle2D(s.x() + dx, s.y() + dy, 0, s.height())
>        };
>    
>        case Split s -> new Rectangle2D[] {
>            new Rectangle2D(...),
>            new Rectangle2D(...)
>        };
>    };
>    ```
> 
>    This is easier to read, and you'll get the compiler checks for free.

I would have agreed with the proposed change, if it were a public API.

This is an internal method, so it was made as low level as possible.  The return value is documented, and the consumer is another part of internal code.  No need to make it more complicated, in my opinion.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102740296

From angorya at openjdk.org  Thu May 22 14:47:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 14:47:04 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v27]
In-Reply-To: <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>
 <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>
Message-ID: <MP6x3QXEE7opUFKKCl8LMPJJSaNlOIz61GWqaf1pgBI=.33401e82-5213-48ef-84b2-aa0a4dcd55b4@github.com>

On Thu, 22 May 2025 00:05:29 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 55 commits:
>> 
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - sealed
>>  - indent
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - twice
>>  - ... and 45 more: https://git.openjdk.org/jfx/compare/d5f569cf...0ac75dae
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1123:
> 
>> 1121:      * @since 25
>> 1122:      */
>> 1123:     public final PathElement[] getStrikeThroughShape(int start, int end) {
> 
> I just noticed that this is named `getStrikeThroughShape` rather than `strikeThroughShape`. The latter would match the similar `rangeShape`, `caretShape`, and `underlineShape` methods. We had discussed that you might propose to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) by deprecating `rangeShape` and `underlineShape` and adding new `getRangeShape` and `getUnderlineShape` methods (although that might be problematic given the `caretShape` property, which necessarily already has a no-arg `getCaretShape()` method).
> 
> Did you name this method `getStrikeThroughShape` with the intention that it would have the fixed semantics of applying the insets from its inception? If so, then I recommend documenting that fact in this method.

Yes, you are right - and I plan to address this in https://bugs.openjdk.org/browse/JDK-8341438 (as it will be a separate change).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102747411

From mstrauss at openjdk.org  Thu May 22 15:08:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 22 May 2025 15:08:07 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <9riBy73SclQdKMRgGTuWVyuhoa9l7ZaYfXTzlR2g41w=.e3ef03bc-fdcf-48b5-b56b-3848f3e8cc2b@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
 <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>
 <9riBy73SclQdKMRgGTuWVyuhoa9l7ZaYfXTzlR2g41w=.e3ef03bc-fdcf-48b5-b56b-3848f3e8cc2b@github.com>
Message-ID: <ypnv601VJJEfDfRDzcfWzL5VuqM3Zfm5btF36_0U4IA=.ab7a2b0f-b900-498c-8933-605b055f0e64@github.com>

On Thu, 22 May 2025 14:40:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Instead of returning `float[]` here, this would be a good candidate to return a discriminated union instead, something like:
>> 
>> sealed interface CaretGeometry {
>>     record Single(float x, float y, float height) implements CaretGeometry {}
>>     record Split(float x1, float x2, float y, float height) implements CaretGeometry {}
>> }
>> 
>> 
>> This has two advantages:
>> 1. It's more expressive, as you don't need to look up what the array values represent.
>> 2. Instead of disciminating between the two cases by inspecting the array length as you do in `PrismLayoutInfo::caretInfoAt`:
>> 
>>    ```java
>>    Rectangle2D[] parts;
>>    if (c.length == 3) {
>>        ..
>>        parts = ...
>>    } else {
>>        ...
>>        parts = ...
>>    }
>>    ```
>>    ...you can use an exhaustive switch expression instead:
>>    ```
>>    Rectangle2D[] parts = switch (c) {
>>        case Single s -> new Rectangle2D[] {
>>            new Rectangle2D(s.x() + dx, s.y() + dy, 0, s.height())
>>        };
>>    
>>        case Split s -> new Rectangle2D[] {
>>            new Rectangle2D(...),
>>            new Rectangle2D(...)
>>        };
>>    };
>>    ```
>> 
>>    This is easier to read, and you'll get the compiler checks for free.
>
> I would have agreed with the proposed change, if it were a public API.
> 
> This is an internal method, so it was made as low level as possible.  The return value is documented, and the consumer is another part of internal code.  No need to make it more complicated, in my opinion.

The point is that it's less complicated to have self-describing, strongly typed, and compiler-checked code. Your code is more complicated because it's brittle, untyped, and less robust against refactoring.

Just to make sure that we're on the same page here: "so it was made as low level as possible" sounds like you deliberately chose to forgo strong typing... to achieve _what_?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102795258

From angorya at openjdk.org  Thu May 22 15:20:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 15:20:06 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <ypnv601VJJEfDfRDzcfWzL5VuqM3Zfm5btF36_0U4IA=.ab7a2b0f-b900-498c-8933-605b055f0e64@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
 <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>
 <9riBy73SclQdKMRgGTuWVyuhoa9l7ZaYfXTzlR2g41w=.e3ef03bc-fdcf-48b5-b56b-3848f3e8cc2b@github.com>
 <ypnv601VJJEfDfRDzcfWzL5VuqM3Zfm5btF36_0U4IA=.ab7a2b0f-b900-498c-8933-605b055f0e64@github.com>
Message-ID: <nTWMa6iKwDox2DO03cU-t65iBiLfkQEpXnsEC9ULrhY=.d36478a1-8e89-4521-8649-0afb4b48fa7f@github.com>

On Thu, 22 May 2025 15:05:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I would have agreed with the proposed change, if it were a public API.
>> 
>> This is an internal method, so it was made as low level as possible.  The return value is documented, and the consumer is another part of internal code.  No need to make it more complicated, in my opinion.
>
> The point is that it's less complicated to have self-describing, strongly typed, and compiler-checked code. Your code is more complicated because it's brittle, untyped, and less robust against refactoring.
> 
> Just to make sure that we're on the same page here: "so it was made as low level as possible" sounds like you deliberately chose to forgo strong typing... to achieve _what_?

There are exactly two internal consumers of that internal API (`PrismLayoutInfo` and `TextUtils.getCaretShape`), and the return value is documented.  I don't want to add any more internal classes, just to repackage the thing into what is eventually delivered via public API, and I cannot use the public API data objects because they are different in the two different use cases.

I don't think it's worth to add a bunch of classes at this level, float[] works just fine.

Is this something you consider to be so important to be an integration blocker?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102821738

From mstrauss at openjdk.org  Thu May 22 15:40:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 22 May 2025 15:40:11 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <nTWMa6iKwDox2DO03cU-t65iBiLfkQEpXnsEC9ULrhY=.d36478a1-8e89-4521-8649-0afb4b48fa7f@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
 <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>
 <n4Rnt3HvGP2wCS7Do1tBIS-KCdf6OsotM0c06oSO_NY=.d6c2b161-8ccb-4691-ba71-369c884d3f9f@github.com>
 <9riBy73SclQdKMRgGTuWVyuhoa9l7ZaYfXTzlR2g41w=.e3ef03bc-fdcf-48b5-b56b-3848f3e8cc2b@github.com>
 <ypnv601VJJEfDfRDzcfWzL5VuqM3Zfm5btF36_0U4IA=.ab7a2b0f-b900-498c-8933-605b055f0e64@github.com>
 <nTWMa6iKwDox2DO03cU-t65iBiLfkQEpXnsEC9ULrhY=.d36478a1-8e89-4521-8649-0afb4b48fa7f@github.com>
Message-ID: <4Vi1aaSotUxbS9pf3mBnO9eakMkwcPdN3XOLzaeWnlo=.b5dcda40-0e8a-437e-9f46-c8bf6e61c268@github.com>

On Thu, 22 May 2025 15:16:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The point is that it's less complicated to have self-describing, strongly typed, and compiler-checked code. Your code is more complicated because it's brittle, untyped, and less robust against refactoring.
>> 
>> Just to make sure that we're on the same page here: "so it was made as low level as possible" sounds like you deliberately chose to forgo strong typing... to achieve _what_?
>
> There are exactly two internal consumers of that internal API (`PrismLayoutInfo` and `TextUtils.getCaretShape`), and the return value is documented.  I don't want to add any more internal classes, just to repackage the thing into what is eventually delivered via public API, and I cannot use the public API data objects because they are different in the two different use cases.
> 
> I don't think it's worth to add a bunch of classes at this level, float[] works just fine.
> 
> Is this something you consider to be so important to be an integration blocker?

Discriminated unions are an amazing tool in the type system if you want to return a number of differently shaped things, which is exactly what you're doing here. You make it sound like giving names to things is somehow a downside, when it's the exact opposite (classes/records are not a finite resource, it's what we use to name things).

I do consider readibility and maintainability to be important, yes. A float array is none of that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2102862116

From andy.goryachev at oracle.com  Thu May 22 16:20:35 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 22 May 2025 16:20:35 +0000
Subject: [External] : richtextarea / documentation / feedback
In-Reply-To: <CAHEiAmcckvYNztHNKpeMZKQTSRXYGJLkSqQCVaj5b3OwXMa27w@mail.gmail.com>
References: <CAHEiAmcckvYNztHNKpeMZKQTSRXYGJLkSqQCVaj5b3OwXMa27w@mail.gmail.com>
Message-ID: <CY8PR10MB726588EFC2DB61462F6EA6DFE599A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Timo:

Good question!

At this point, the embedded images can be used in a custom model, or a view-only model.  The basic idea is that the model creates a RichParagraph in its getParagraph(int index) method.  Note that the RichParagraph is just a way to communicate the model's data, the model may use some other mechanism for storing its data.

You use RichParagraph.Builder to build the paragraph.  Use addInlineNode(Supplier<Node> generator) to add a Node that contain the actual image.  You can use ImageCellPane  for that purpose, but in reality I suspect the actual Node that presents an image data may depend on the application requirements.

Alternatively, you can use SimpleViewOnlyStyledModel, see an example in the DemoModel:138.

Finally, support for embedded images is currently absent in the RichTextModel (the default model for RichTextArea).  I've created https://bugs.openjdk.org/browse/JDK-8357582 to rectify that.

Hope this helps, and thank you for the feedback - keep it coming!

-andy



From: Timo <REDACTED at REDACTED>
Date: Thursday, May 22, 2025 at 04:18
To: Andy Goryachev <andy.goryachev at oracle.com>
Subject: [External] : richtextarea / documentation / feedback
Hi Andy

Thanks for the richtextarea which is highly appreciated and needed.
Unfortunately, i dont know how to use it when coming to more
sophisticated examples - like a RichParagraph.

Reading the readme did not help as it ends with the builder.
How to append it to the editor?

Feedback, if i can go ahead solving this issue, i need to handle images. otherwise
it does not make sense at all.  If i manage to do so i can go ahead and gladly share
feedback. So far, it looks very good and reliable.

If you can provide a code snippet on that would be great.

Thank you for your effort!
Best regards, Timo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250522/13ff297e/attachment-0001.htm>

From sykora at openjdk.org  Thu May 22 16:39:55 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 22 May 2025 16:39:55 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <qk4R30T21Gk4hMfpLVIOa00LaxcwFkGfcvEJV-_UKM8=.344d7712-4439-4548-aabb-52dfde3017f3@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

I've managed to build and do some basic testing after updating to Visual Studio 17.13.2

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2861905678

From kcr at openjdk.org  Thu May 22 16:53:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 May 2025 16:53:07 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows [v2]
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
 - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
 - Only define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' for ICU on Windows
 - Define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' when compiling web (ICU), graphics, and media
 - 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

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

Changes: https://git.openjdk.org/jfx/pull/1807/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1807&range=01
  Stats: 21 lines in 14 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1807.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1807/head:pull/1807

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

From kcr at openjdk.org  Thu May 22 16:55:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 May 2025 16:55:57 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <QTDx2DqcufUGx7JzbXPUuP8Pkx4PGXPcdnTssi0W1bY=.1e1663b8-e23e-4319-bf2a-044acec8914e@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

I merged with master to resolve the trivial merge conflict (kdiff3 resolved the conflict automatically).

As a result, a re-review is required.

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

PR Comment: https://git.openjdk.org/jfx/pull/1807#issuecomment-2901942547

From angorya at openjdk.org  Thu May 22 17:18:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 17:18:23 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v28]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <KJPm9Dhlni-NJ4FRk9pEzQLbpnOxN7N43aw4Z9OXIVo=.27124c0f-5265-49b6-9aa6-15ab053fcdbb@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  caret geometry

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/0ac75dae..c885173b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=27
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=26-27

  Stats: 174 lines in 6 files changed: 71 ins; 75 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

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

From angorya at openjdk.org  Thu May 22 18:02:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 18:02:02 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v27]
In-Reply-To: <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>
 <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>
Message-ID: <V0tLxAEZR8N2x0CYRUlcU3lDhGFvTwFzwaLRMp73ayk=.b48c3777-0853-49f1-95af-3f91db5a629d@github.com>

On Thu, 22 May 2025 00:05:29 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 55 commits:
>> 
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - sealed
>>  - indent
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - twice
>>  - ... and 45 more: https://git.openjdk.org/jfx/compare/d5f569cf...0ac75dae
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1123:
> 
>> 1121:      * @since 25
>> 1122:      */
>> 1123:     public final PathElement[] getStrikeThroughShape(int start, int end) {
> 
> I just noticed that this is named `getStrikeThroughShape` rather than `strikeThroughShape`. The latter would match the similar `rangeShape`, `caretShape`, and `underlineShape` methods. We had discussed that you might propose to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) by deprecating `rangeShape` and `underlineShape` and adding new `getRangeShape` and `getUnderlineShape` methods (although that might be problematic given the `caretShape` property, which necessarily already has a no-arg `getCaretShape()` method).
> 
> Did you name this method `getStrikeThroughShape` with the intention that it would have the fixed semantics of applying the insets from its inception? If so, then I recommend documenting that fact in this method.

We discussed this with @kevinrushforth - I am going to remove the `getStrikeThroughShape()` method from Text/TextFlow in this PR, and add it under either a separate ticket, or as a part of https://bugs.openjdk.org/browse/JDK-8341438

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2103122008

From angorya at openjdk.org  Thu May 22 18:11:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 18:11:16 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v29]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <gNihNH7i8s-mmVGa2C8F2-paUXKqy6Nx9eZVPFmuMZs=.c517f878-5664-43ab-8b81-3bedc6f3b28c@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  removed getStrikeThroughShape

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/c885173b..0f02fe9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=28
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=27-28

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

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

From sykora at openjdk.org  Thu May 22 18:33:57 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 22 May 2025 18:33:57 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows [v2]
In-Reply-To: <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
 <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
Message-ID: <zZ2OMVg5k7MrVsU8d_SAKkb-Zlp-eYJ3Iu-LXJiwtDI=.fa433c78-03c0-4de6-8728-2e49b9f328ce@github.com>

On Thu, 22 May 2025 16:53:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
>> 
>> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
>> 
>> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Only define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' for ICU on Windows
>  - Define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' when compiling web (ICU), graphics, and media
>  - 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2862219889

From angorya at openjdk.org  Thu May 22 19:00:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 19:00:19 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v30]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <PtW0B_U-x3P4Vqcwb8nMzKNAtBfHaA6WsX8fIqSMQV8=.5d0d84b0-243a-48f5-a9f6-ddd9a64f147a@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

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 ag.text.layout.api
 - cleanup
 - removed getStrikeThroughShape
 - caret geometry
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - sealed
 - indent
 - ... and 49 more: https://git.openjdk.org/jfx/compare/59c2b759...ab8bd9cb

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=29
  Stats: 1565 lines in 13 files changed: 1469 ins; 52 del; 44 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

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

From angorya at openjdk.org  Thu May 22 19:09:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 May 2025 19:09:00 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v27]
In-Reply-To: <V0tLxAEZR8N2x0CYRUlcU3lDhGFvTwFzwaLRMp73ayk=.b48c3777-0853-49f1-95af-3f91db5a629d@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <1m--nXiOUflu-_5qgo3bfpcXYytZoRuxeqb3I7ZOSDU=.17d3bc9f-2702-41e4-bb98-d3578eb6cfe7@github.com>
 <jYxEqQTKYdhQqe5OBO3zshs-LDNI3cF368zCqRtM1ms=.33c3be8b-8db9-4b28-9920-899fcb705ff1@github.com>
 <V0tLxAEZR8N2x0CYRUlcU3lDhGFvTwFzwaLRMp73ayk=.b48c3777-0853-49f1-95af-3f91db5a629d@github.com>
Message-ID: <KLl-r3RTfeFvlGFZnjxs4R4DNweZn1r_1ekVnXZ5SmM=.02c06d77-bef5-4bc5-849e-b1b9a72f5350@github.com>

On Thu, 22 May 2025 17:59:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1123:
>> 
>>> 1121:      * @since 25
>>> 1122:      */
>>> 1123:     public final PathElement[] getStrikeThroughShape(int start, int end) {
>> 
>> I just noticed that this is named `getStrikeThroughShape` rather than `strikeThroughShape`. The latter would match the similar `rangeShape`, `caretShape`, and `underlineShape` methods. We had discussed that you might propose to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) by deprecating `rangeShape` and `underlineShape` and adding new `getRangeShape` and `getUnderlineShape` methods (although that might be problematic given the `caretShape` property, which necessarily already has a no-arg `getCaretShape()` method).
>> 
>> Did you name this method `getStrikeThroughShape` with the intention that it would have the fixed semantics of applying the insets from its inception? If so, then I recommend documenting that fact in this method.
>
> We discussed this with @kevinrushforth - I am going to remove the `getStrikeThroughShape()` method from Text/TextFlow in this PR, and add it under either a separate ticket, or as a part of https://bugs.openjdk.org/browse/JDK-8341438

Created https://bugs.openjdk.org/browse/JDK-8357594 for `Text::strikeThroughShape` and `TextFlow::getStrikeThroughShape`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2103231779

From mhanl at openjdk.org  Thu May 22 19:39:55 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 22 May 2025 19:39:55 GMT
Subject: Integrated: 8169285: Re-enable javafx.swt tests
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <rIbKNyQlloHVeq9ot-cb5D5sxW5UASJyoS8bnlaSaNU=.d1197860-bf0e-456e-a6e9-f2c12c1f9ff4@github.com>

On Wed, 16 Apr 2025 18:48:09 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR enables `javafx.swt` tests for:
> - Windows
> 
> Disabled on:
> - Linux, since some distros seems to have problems -> https://bugs.openjdk.org/browse/JDK-8356688
> - MacOS: The following warning is printed right before the error: `***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread` -> https://bugs.openjdk.org/browse/JDK-8356687

This pull request has now been integrated.

Changeset: 9950d33c
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9950d33ccdb1edd61b4a15019f25603e65fa863b
Stats:     10 lines in 1 file changed: 1 ins; 7 del; 2 mod

8169285: Re-enable javafx.swt tests

Reviewed-by: kcr

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

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

From mhanl at openjdk.org  Thu May 22 20:12:00 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 22 May 2025 20:12:00 GMT
Subject: RFR: 8357157: Exception thrown from AnimationTimer freezes
 application [v3]
In-Reply-To: <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
References: <jGBYoS_uCelpH1YJvpI3cfsTGvAVVsK8NCQlxZRKxUA=.786daa09-2a03-45e0-abef-c7020294abc8@github.com>
 <KrS0WOJvFoADEqys579dFFYS_HrmP-HPXLLAXNJV2p4=.30307de1-0dc5-4ff6-a2a0-9178497fc8fe@github.com>
Message-ID: <0flK-I8QNvI4GhwGWmwDwzFNsjWx60rMCO12ca8TdOY=.0a333165-0b1c-4e64-a499-7ab2de09328d@github.com>

On Sat, 17 May 2025 12:24:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX application freezes. The reason is that the user exception will bubble up into framework code, preventing the normal operation of JavaFX.
>> 
>> The following program demonstrates the defect:
>> 
>> 
>> public class FailingAnimationTimer extends Application {
>>     @Override
>>     public void start(Stage stage) throws Exception {
>>         var button = new Button("start timer");
>>         button.setOnAction(_ -> {
>>             var timer = new AnimationTimer() {
>>                 @Override
>>                 public void handle(long l) {
>>                     throw new RuntimeException("foo");
>>                 }
>>             };
>> 
>>             timer.start();
>>         });
>> 
>>         var root = new HBox();
>>         root.getChildren().add(new TextField("test"));
>>         root.getChildren().add(button);
>>         stage.setScene(new Scene(root));
>>         stage.show();
>>     }
>> }
>> 
>> 
>> The solution is to not allow user exceptions to bubble up into animation framework code. If an exception occurs, it is instead sent to the current thread's uncaught exception handler. This is the same thing that we already do for exceptions thrown by invalidation listeners and change listeners.
>> 
>> In addition to that, a failing animation timer has the potential to spam logs, which is why I introduced a cut-off value at 100 exceptions for each individual timer, after which no further exceptions from this particular timer are sent to the uncaught exception handler. After reaching the cut-off value, the following warning is logged:
>> 
>> `WARNING: Too many exceptions thrown by AnimationTimer, ignoring further exceptions. The cut-off number can be set with the system property com.sun.scenario.animation.failingTimerThreshold (current = 100).`
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove system property

A bit late, but I checked the PR and also had mixed feelings about the error limit stuff (rest is fine!). 
But I actually found out, that there is something similar in Java already: `-Xmaxwarns` and `-Xmaxerrs`, which is also 100 by default (I saw that recently in a Gradle build). 

Which made me feel like this solution is fine and the solution is similar to things which are in Java already for years. At least we do not do something completely new.

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

PR Comment: https://git.openjdk.org/jfx/pull/1811#issuecomment-2902429848

From almatvee at openjdk.org  Thu May 22 20:23:59 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 22 May 2025 20:23:59 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows [v2]
In-Reply-To: <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
 <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
Message-ID: <EFXyWHOmvsHuKnTxa7K6TNngVVfizaAMDJ6QVowXs4o=.a810403b-1198-47c5-a072-203341d06cfd@github.com>

On Thu, 22 May 2025 16:53:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
>> 
>> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
>> 
>> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Only define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' for ICU on Windows
>  - Define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' when compiling web (ICU), graphics, and media
>  - 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2862474667

From mstrauss at openjdk.org  Thu May 22 21:53:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 22 May 2025 21:53:01 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v30]
In-Reply-To: <PtW0B_U-x3P4Vqcwb8nMzKNAtBfHaA6WsX8fIqSMQV8=.5d0d84b0-243a-48f5-a9f6-ddd9a64f147a@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <PtW0B_U-x3P4Vqcwb8nMzKNAtBfHaA6WsX8fIqSMQV8=.5d0d84b0-243a-48f5-a9f6-ddd9a64f147a@github.com>
Message-ID: <W3Z9IF0orVraZ0BenFbwpCq2bhI6lLF9KjQ3nh3K0rA=.039bc9ae-1fdb-492b-8399-09de74ae08bd@github.com>

On Thu, 22 May 2025 19:00:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> 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 ag.text.layout.api
>  - cleanup
>  - removed getStrikeThroughShape
>  - caret geometry
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - sealed
>  - indent
>  - ... and 49 more: https://git.openjdk.org/jfx/compare/59c2b759...ab8bd9cb

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismLayoutInfo.java line 74:

> 72:         TextLine[] lines = layout.getLines();
> 73:         Insets m = insets();
> 74:         double dx = m.getLeft(); // TODO rtl?

This comment looks like it's a question to the reader. Does the code not work for RTL layouts?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2103443199

From lkostyra at openjdk.org  Fri May 23 11:55:58 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 23 May 2025 11:55:58 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show
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: <j6CAM5Xaj65I8tQCzG9LXhm0BmtPCG8MnmulSHtWfS4=.5c5bf1e9-13d4-4c34-8aba-fee74213fee6@github.com>

On Tue, 13 May 2025 09:10:27 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 through Gradle Daemon (am...

Renamed the issue title to better reflect what the change actually does

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

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

From zelmidaoui at openjdk.org  Fri May 23 15:58:00 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 23 May 2025 15:58:00 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <xOWQBtu9qSuInozG3rlQFOG4TIwJKRHDH4gk-6TyNz4=.a83565fb-220e-48aa-aa24-43043dc6c684@github.com>

On Mon, 28 Apr 2025 18:27:37 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
>> 
>> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
>> 
>> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
>> 
>> | isPopupTriggered on: | Windows  | macOS | Linux |
>> | ------------- | ------------- | ------------- | ------------- |
>> | mousePressed  | false  | true | true |
>> | mouseReleased  | true  | false | false?|
>> 
>> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
>> 
>>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
>> 
>> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
>> 
>> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.
>
> Jose Pereda 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

LGTM, test fail in master and work with the fix

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

Marked as reviewed by zelmidaoui (Author).

PR Review: https://git.openjdk.org/jfx/pull/1754#pullrequestreview-2864917030

From tsayao at openjdk.org  Sat May 24 21:07:13 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 24 May 2025 21:07:13 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v22]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <wnToKmYQFG8joZkQLU-06F3odaz_Y1jWCsNsCXu1G2s=.5ad95246-b587-4154-9968-76a00cd84e46@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
 - - Fixes on TestStage
 - - Review fixes
   - Fix Focus
   - Improvements on TestStage to assist testing
 - Merge branch 'master' into 8354943
 - Fix non-debug build
 - Review fixes
 - Fix TestStage conflicting value listener
 - Merge master
 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	tests/system/src/test/java/test/javafx/scene/RestoreSceneSizeTest.java
 - ... and 14 more: https://git.openjdk.org/jfx/compare/9950d33c...f455bb4f

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=21
  Stats: 4135 lines in 28 files changed: 2881 ins; 749 del; 505 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From mstrauss at openjdk.org  Sun May 25 00:19:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 25 May 2025 00:19:36 GMT
Subject: RFR: 8345348: CSS media feature queries [v25]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>

> 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 40 commits:

 - Merge branch 'master' into feature/media-queries
 - add -fx vendor prefix to prefers-persistent-scrollbars
 - cssref documentation changes
 - added test
 - canonical modifier order
 - improve synchronization in PreferenceProperties
 - review comments
 - added tests
 - documentation
 - use serializedId in MediaQuerySerializer
 - ... and 30 more: https://git.openjdk.org/jfx/compare/9950d33c...b61f1918

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=24
  Stats: 5275 lines in 41 files changed: 4125 ins; 1041 del; 109 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 kizune at openjdk.org  Tue May 27 04:23:42 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 27 May 2025 04:23:42 GMT
Subject: RFR: 8356983: Create implementation of NSAccessibilityImage protocol
Message-ID: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>

- Initial implementation;
- Added accessible text to image view in Ensemble8 to make testing of this feature with Ensemble8 more viable;

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

Commit messages:
 - 8356983: Create implementation of NSAccessibilityImage protocol

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

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

From zelmidaoui at openjdk.org  Tue May 27 13:37:18 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 27 May 2025 13:37:18 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v2]
In-Reply-To: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
Message-ID: <iyDn2NOJIfLJvLFN0BGn1gT_yMnZB3Y1LYkasGWsgak=.74f06e83-fafa-4256-a6be-084a57f1d74a@github.com>

> When the Root TreeItem is set to null, need to relayout to show the children items

Ziad El Midaoui 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8341281.RootTreeItem
 - Fixed issue with TreeTableView not showing the root's children when set to null

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1767/files
  - new: https://git.openjdk.org/jfx/pull/1767/files/c80550e4..a7747486

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

  Stats: 125100 lines in 321 files changed: 30056 ins; 52530 del; 42514 mod
  Patch: https://git.openjdk.org/jfx/pull/1767.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1767/head:pull/1767

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

From jskov at mada.dk  Tue May 27 13:41:26 2025
From: jskov at mada.dk (Jesper Skov)
Date: Tue, 27 May 2025 15:41:26 +0200 (CEST)
Subject: Build logic renovation?
Message-ID: <ORGyUxQ--F-9@mada.dk>

Hi there!

Would there be interest in reworking the build logic?

All the procedural Gradle in one large file makes it hard to understand the build logic.
It looks very complex.
And it may be performing below optimum (this is just a conjecture).

I know that the current build is very obviously working.
And that there may good reasons to keep it in its current form.
(familiarity, ability to do inject additional logic in downstream commercial builds, etc.)

But if there is an interest, I would like to make the build more idiomatic Gradle.
And when possible, make it fully declarative(1).


I do not have a magical solution in the drawer.
I would like to see the response to this mail, before I start looking at the problem in earnest.

Changing the build would be an explorative and iterative task.
And I would need to know if there are some non-obvious out-of-tree features that need special handling.

But hopefully it would provide some useful benefits on the way.
Even if the final goal is not reached.

Up front I expect to do at least:

* Move dependencies to catalogs (2).
* Move logic into buildSrc to define Tasks and Plugins (in Java).
* Use lazy task registration.
* Use better task input definitions (3).
* Use individual build files in each module.

I can understand if you would be wary about this proposal; I may not be able to complete the transition from the current to a new build.
So I suggest that maybe the work be done in separate build files for a start.
The new build could be invoked with an extra argument to Gradle.

This would make it simple to compare the output of the current and the new build.
And to purge the new build if that becomes necessary.


Looking forward to your replies!

Thanks,
Jesper Skov


1: https://blog.gradle.org/declarative-gradle-april-2025-update
2: https://docs.gradle.org/current/userguide/version_catalogs.html#sec:version-catalog-declaration
3: https://bugs.openjdk.org/browse/JDK-8290976


From zelmidaoui at openjdk.org  Tue May 27 14:03:15 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 27 May 2025 14:03:15 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v3]
In-Reply-To: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
Message-ID: <AB3FXH4qKcRpdKGMRPiiLO9N4ujbUwtSrcYT8LJsasM=.b00b27d7-9dc9-49cf-8aca-50e149473166@github.com>

> When the Root TreeItem is set to null, need to relayout to show the children items

Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem
 - Headfull Test added

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1767/files
  - new: https://git.openjdk.org/jfx/pull/1767/files/a7747486..bf0f0a13

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

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

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

From angorya at openjdk.org  Tue May 27 15:06:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 15:06:43 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v31]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <y4TtXRYJW3xmb9IDutID9jc1zKy2oeqJMYCVCTO_Xhw=.e08f07c8-deae-4b32-b7b7-f63945873c0e@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> 
> 
> ## WARNINGS
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> Also, the RTL support is out of scope for this PR, due to multiple pre-existing conditions, see https://bugs.openjdk.org/browse/JDK-8343557
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

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

 - cleanup
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - cleanup
 - removed getStrikeThroughShape
 - caret geometry
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - ... and 51 more: https://git.openjdk.org/jfx/compare/9950d33c...de1016be

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

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=30
  Stats: 1570 lines in 13 files changed: 1474 ins; 52 del; 44 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

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

From angorya at openjdk.org  Tue May 27 15:06:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 15:06:44 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v30]
In-Reply-To: <W3Z9IF0orVraZ0BenFbwpCq2bhI6lLF9KjQ3nh3K0rA=.039bc9ae-1fdb-492b-8399-09de74ae08bd@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <PtW0B_U-x3P4Vqcwb8nMzKNAtBfHaA6WsX8fIqSMQV8=.5d0d84b0-243a-48f5-a9f6-ddd9a64f147a@github.com>
 <W3Z9IF0orVraZ0BenFbwpCq2bhI6lLF9KjQ3nh3K0rA=.039bc9ae-1fdb-492b-8399-09de74ae08bd@github.com>
Message-ID: <DVWRqBUHmlOkLaO3z-G3SXI-IKzakhL7ST8mfrLm3u4=.a075ceab-2a8f-4178-ab3d-046364d06989@github.com>

On Thu, 22 May 2025 21:47:22 GMT, Michael Strau? <mstrauss 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 59 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - cleanup
>>  - removed getStrikeThroughShape
>>  - caret geometry
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - sealed
>>  - indent
>>  - ... and 49 more: https://git.openjdk.org/jfx/compare/59c2b759...ab8bd9cb
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismLayoutInfo.java line 74:
> 
>> 72:         TextLine[] lines = layout.getLines();
>> 73:         Insets m = insets();
>> 74:         double dx = m.getLeft(); // TODO rtl?
> 
> This comment looks like it's a question to the reader. Does the code not work for RTL layouts?

JavaFX does not support RTL fully - there is a whole series of issues waiting to be fixed.
See https://bugs.openjdk.org/browse/JDK-8343557

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r2103461360

From angorya at openjdk.org  Tue May 27 15:43:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 15:43:57 GMT
Subject: RFR: 8356983: Create implementation of NSAccessibilityImage
 protocol
In-Reply-To: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
References: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
Message-ID: <DX-N3ak5QgQgIWEARPNbLiyzMp_vYsw4G2-71ngpt38=.1a540558-8025-4005-a0ce-aedc61814e19@github.com>

On Tue, 27 May 2025 04:18:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Initial implementation;
> - Added accessible text to image view in Ensemble8 to make testing of this feature with Ensemble8 more viable;

Marked as reviewed by angorya (Reviewer).

Added ImageView page to the monkey tester:
https://github.com/andy-goryachev-oracle/MonkeyTest

VoiceOver announces the accessible text set on ImageView (the image view was set focus traversable).

Also the following is being logged when Logging -> Accessibility is turned on:


{time:1748360254874, log:"accessibility", "ROLE":""IMAGE_VIEW""}
{time:1748360254874, log:"accessibility", "TEXT":""zzyzx""}
{time:1748360254874, log:"accessibility", "ROLE":""IMAGE_VIEW""}
{time:1748360254874, log:"accessibility", "TEXT":""zzyzx""}
{time:1748360254874, log:"accessibility", "ROLE":""IMAGE_VIEW""}

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

PR Review: https://git.openjdk.org/jfx/pull/1816#pullrequestreview-2871611856
PR Comment: https://git.openjdk.org/jfx/pull/1816#issuecomment-2913061531

From angorya at openjdk.org  Tue May 27 15:46:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 15:46:00 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v3]
In-Reply-To: <AB3FXH4qKcRpdKGMRPiiLO9N4ujbUwtSrcYT8LJsasM=.b00b27d7-9dc9-49cf-8aca-50e149473166@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
 <AB3FXH4qKcRpdKGMRPiiLO9N4ujbUwtSrcYT8LJsasM=.b00b27d7-9dc9-49cf-8aca-50e149473166@github.com>
Message-ID: <f0fw3WBvrYMzg5ZV5Ru7Z56QSetN_T-vL4e5lguijpU=.482e900c-1d8d-4e81-a5a2-6bcf028e2e9a@github.com>

On Tue, 27 May 2025 14:03:15 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> When the Root TreeItem is set to null, need to relayout to show the children items
>
> Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem
>  - Headfull Test added

tests/system/src/test/java/test/robot/javafx/scene/treetableview/TreeTableViewChangeRootTest.java line 160:

> 158:         }
> 159:     }
> 160: }

missing newline

(it's always a good idea to go through the files once the PR is created)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1767#discussion_r2109548816

From zelmidaoui at openjdk.org  Tue May 27 16:09:52 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 27 May 2025 16:09:52 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v4]
In-Reply-To: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
Message-ID: <mYTOiBzaaSM5mCTXpmUB30I4KhIcbW1EcOWI36fXFEI=.a846fbc7-8e22-48ae-a43d-32c6efc051d5@github.com>

> When the Root TreeItem is set to null, need to relayout to show the children items

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Minor change : new line added

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1767/files
  - new: https://git.openjdk.org/jfx/pull/1767/files/bf0f0a13..dc0de460

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

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

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

From zelmidaoui at openjdk.org  Tue May 27 16:09:53 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 27 May 2025 16:09:53 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v3]
In-Reply-To: <f0fw3WBvrYMzg5ZV5Ru7Z56QSetN_T-vL4e5lguijpU=.482e900c-1d8d-4e81-a5a2-6bcf028e2e9a@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
 <AB3FXH4qKcRpdKGMRPiiLO9N4ujbUwtSrcYT8LJsasM=.b00b27d7-9dc9-49cf-8aca-50e149473166@github.com>
 <f0fw3WBvrYMzg5ZV5Ru7Z56QSetN_T-vL4e5lguijpU=.482e900c-1d8d-4e81-a5a2-6bcf028e2e9a@github.com>
Message-ID: <CdgxPsUGUUvjdaORMZCQDU55AGOr4yHqo2_2dQSTTxs=.440496c2-916b-42f6-b4ef-eb94ec232c8b@github.com>

On Tue, 27 May 2025 15:43:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/8341281.RootTreeItem' into 8341281.RootTreeItem
>>  - Headfull Test added
>
> tests/system/src/test/java/test/robot/javafx/scene/treetableview/TreeTableViewChangeRootTest.java line 160:
> 
>> 158:         }
>> 159:     }
>> 160: }
> 
> missing newline
> 
> (it's always a good idea to go through the files once the PR is created)

I added it , thanks

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1767#discussion_r2109617874

From angorya at openjdk.org  Tue May 27 17:09:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 17:09:56 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v4]
In-Reply-To: <mYTOiBzaaSM5mCTXpmUB30I4KhIcbW1EcOWI36fXFEI=.a846fbc7-8e22-48ae-a43d-32c6efc051d5@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
 <mYTOiBzaaSM5mCTXpmUB30I4KhIcbW1EcOWI36fXFEI=.a846fbc7-8e22-48ae-a43d-32c6efc051d5@github.com>
Message-ID: <wt_JBem8KegAyB3Rn34AN5UEAYB_CGf9TvpnxUIDsdA=.c95f7341-1931-49d4-ac53-831fc4740dce@github.com>

On Tue, 27 May 2025 16:09:52 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> When the Root TreeItem is set to null, need to relayout to show the children items
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor change : new line added

looks good in the monkey tester and in the newly created headful test.
thanks for fixing the issue!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1767#pullrequestreview-2871894514

From angorya at openjdk.org  Tue May 27 17:13:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 17:13:01 GMT
Subject: RFR: 8345348: CSS media feature queries [v25]
In-Reply-To: <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>
Message-ID: <vJ31cTW87hwD8rAM6pu5JIgufpKCufsNUQXPN0OHQeM=.6e04bd61-531b-43c1-872c-1519db6c5cde@github.com>

On Sun, 25 May 2025 00:19:36 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 40 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - add -fx vendor prefix to prefers-persistent-scrollbars
>  - cssref documentation changes
>  - added test
>  - canonical modifier order
>  - improve synchronization in PreferenceProperties
>  - review comments
>  - added tests
>  - documentation
>  - use serializedId in MediaQuerySerializer
>  - ... and 30 more: https://git.openjdk.org/jfx/compare/9950d33c...b61f1918

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

> 6569:          *     <caption>Media Feature</caption>
> 6570:          *     <tbody>
> 6571:          *         <tr><th>Name</th><td><code>-fx-prefers-persistent-scrollbars</code></td></tr>

why the change to -fx for persistent scroll bars and not the others?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2109738230

From mstrauss at openjdk.org  Tue May 27 17:21:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 27 May 2025 17:21:07 GMT
Subject: RFR: 8345348: CSS media feature queries [v25]
In-Reply-To: <vJ31cTW87hwD8rAM6pu5JIgufpKCufsNUQXPN0OHQeM=.6e04bd61-531b-43c1-872c-1519db6c5cde@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>
 <vJ31cTW87hwD8rAM6pu5JIgufpKCufsNUQXPN0OHQeM=.6e04bd61-531b-43c1-872c-1519db6c5cde@github.com>
Message-ID: <NRlfBiUEPWzNx3dXIKIwMLnPs5CpEBePaGWA1eEDjiQ=.49793a11-a93b-4055-ac95-df471a305e33@github.com>

On Tue, 27 May 2025 17:10:19 GMT, Andy Goryachev <angorya 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 40 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - add -fx vendor prefix to prefers-persistent-scrollbars
>>  - cssref documentation changes
>>  - added test
>>  - canonical modifier order
>>  - improve synchronization in PreferenceProperties
>>  - review comments
>>  - added tests
>>  - documentation
>>  - use serializedId in MediaQuerySerializer
>>  - ... and 30 more: https://git.openjdk.org/jfx/compare/9950d33c...b61f1918
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6571:
> 
>> 6569:          *     <caption>Media Feature</caption>
>> 6570:          *     <tbody>
>> 6571:          *         <tr><th>Name</th><td><code>-fx-prefers-persistent-scrollbars</code></td></tr>
> 
> why the change to -fx for persistent scroll bars and not the others?

The other queries are standardized and universally agreed upon, whereas this one isn't. It's there because we have a corresponding platform preference, so I think a vendor prefix is in order.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2109754086

From angorya at openjdk.org  Tue May 27 17:41:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 May 2025 17:41:00 GMT
Subject: RFR: 8345348: CSS media feature queries [v25]
In-Reply-To: <NRlfBiUEPWzNx3dXIKIwMLnPs5CpEBePaGWA1eEDjiQ=.49793a11-a93b-4055-ac95-df471a305e33@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>
 <vJ31cTW87hwD8rAM6pu5JIgufpKCufsNUQXPN0OHQeM=.6e04bd61-531b-43c1-872c-1519db6c5cde@github.com>
 <NRlfBiUEPWzNx3dXIKIwMLnPs5CpEBePaGWA1eEDjiQ=.49793a11-a93b-4055-ac95-df471a305e33@github.com>
Message-ID: <xfhY4w3iZmxHgvriyUkcnomZjj7iQq7FSFoOQtB0rDk=.f4595ffc-3a17-4874-b03b-e93a9034c278@github.com>

On Tue, 27 May 2025 17:18:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6571:
>> 
>>> 6569:          *     <caption>Media Feature</caption>
>>> 6570:          *     <tbody>
>>> 6571:          *         <tr><th>Name</th><td><code>-fx-prefers-persistent-scrollbars</code></td></tr>
>> 
>> why the change to -fx for persistent scroll bars and not the others?
>
> The other queries are standardized and universally agreed upon, whereas this one isn't. It's there because we have a corresponding platform preference, so I think a vendor prefix is in order.

not sure what you mean by "standardized and universally agreed upon", but -fx strikes me as confusing (is it a style?)  maybe `fx-prefers-persistent-scrollbars`?

not a big deal though, as long as it's properly documented (it is).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2109793604

From andy.goryachev at oracle.com  Tue May 27 17:51:30 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 27 May 2025 17:51:30 +0000
Subject: CodeArea: request to raise priority of JDK-8357405 (text length
 metrics for ContentChange)
In-Reply-To: <8d32334e-cb6e-4d62-9138-a917a8549ecc@gmail.com>
References: <8d32334e-cb6e-4d62-9138-a917a8549ecc@gmail.com>
Message-ID: <CY8PR10MB72656DE7D085707CE16310B4E564A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Pavel:

This is not a trivial request.  Currently, there is not easy way to control (override) the behavior of the CodeModel with respect to line endings.  Line endings are not stored in the model, but they are emitted when saving/copying.

Perhaps we ought to add a dedicated property to the model (line endings: CR/LF/CRLF/PLATFORM?) which would allow the application to specify the behavior and allow the model to perform the offset calculations.

The other issue is that the CodeArea supports large models (CodeTextModel with a custom BasicTextModel.Content).  Computing offsets in a large model not only may take a long time, but also produce result that does not fit into 31 bits.  Which means, for all intents and purposes, this functionality should be implemented by a custom model.

What do you think?

Cheers,
-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, May 22, 2025 at 05:29
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange)
I'd like to kindly ask for consideration in raising the priority of JDK-8357405 about adding text length
metrics to ContentChange for removed/inserted text for CodeArea.

The reason for this request is that accurate and reliable information about text changes is essential
when integrating CodeArea with code processing libraries. Currently, CodeArea does not provide
such information.

As a result, CodeArea can only be reliably used in read-only mode at the moment ? which severely
limits its applicability in real-world applications.

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250527/ae2d5f08/attachment-0001.htm>

From mstrauss at openjdk.org  Tue May 27 17:56:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 27 May 2025 17:56:01 GMT
Subject: RFR: 8345348: CSS media feature queries [v25]
In-Reply-To: <xfhY4w3iZmxHgvriyUkcnomZjj7iQq7FSFoOQtB0rDk=.f4595ffc-3a17-4874-b03b-e93a9034c278@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <Z0ZezPLsKNjRrgzPap1Wz9SXECYWebV-0MITTGYExJs=.10b2ded6-d5d9-4154-9e2d-d1f0e303ece7@github.com>
 <vJ31cTW87hwD8rAM6pu5JIgufpKCufsNUQXPN0OHQeM=.6e04bd61-531b-43c1-872c-1519db6c5cde@github.com>
 <NRlfBiUEPWzNx3dXIKIwMLnPs5CpEBePaGWA1eEDjiQ=.49793a11-a93b-4055-ac95-df471a305e33@github.com>
 <xfhY4w3iZmxHgvriyUkcnomZjj7iQq7FSFoOQtB0rDk=.f4595ffc-3a17-4874-b03b-e93a9034c278@github.com>
Message-ID: <_lJp3263pWlIgLg6DWW2Mj_HgDF9jO_JUkP7-np2nUI=.3568ddf1-039b-4375-b8f0-77d0e5ff7946@github.com>

On Tue, 27 May 2025 17:38:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The other queries are standardized and universally agreed upon, whereas this one isn't. It's there because we have a corresponding platform preference, so I think a vendor prefix is in order.
>
> not sure what you mean by "standardized and universally agreed upon", but -fx strikes me as confusing (is it a style?)  maybe `fx-prefers-persistent-scrollbars`?
> 
> not a big deal though, as long as it's properly documented (it is).

In the CSS universe, `foo` identifies a standardized name (i.e. it's been around long enough that everyone has agreed on it, not just a single vendor), `-fx-foo` identifies a vendor-specific name (in this case FX, other vendor-specific prefixes are `-ms-`, `-webkit-`, etc.), and `--foo` identifies a user name. That's why most JavaFX CSS property names have the `-fx-` vendor prefix (but not all: `visibility` and `transition` come without a vendor prefix).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2109817347

From john at status6.com  Tue May 27 19:27:23 2025
From: john at status6.com (John Neffenger)
Date: Tue, 27 May 2025 12:27:23 -0700
Subject: Build logic renovation?
In-Reply-To: <ORGyUxQ--F-9@mada.dk>
References: <ORGyUxQ--F-9@mada.dk>
Message-ID: <fc572df1-b083-4d08-af90-7a61519edc5a@status6.com>

Hi, Jesper. My comments below are not meant to discourage you entirely 
from your plans -- really! :-) -- but rather to help you understand, 
based on my own experience, the scope of the work involved.

On 5/27/25 6:41 AM, Jesper Skov wrote:
> Would there be interest in reworking the build logic?

Yes, but perhaps more like this:

Building OpenJFX using JDK
https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/

> All the procedural Gradle in one large file makes it hard to understand the build logic.

Indeed.

> It looks very complex.

It is very complex.

> And it may be performing below optimum (this is just a conjecture).

Without a doubt.

> I know that the current build is very obviously working.

Barely. :-)

> And that there may good reasons to keep it in its current form.

No, not really, except for the "very obviously working" part.

> But if there is an interest, I would like to make the build more idiomatic Gradle.

Personally, I'm done with Gradle for any of my own projects. It's 
difficult to pin down precisely the way in which Gradle fails to be a 
good build system, but I think Bruce Eckel summarized it best in his 
article below:

Jan 2, 2021 - 16 minute read
The Problem with Gradle
https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/

> Changing the build would be an explorative and iterative task.

The JavaFX build system is remarkably complicated. It is based on Gradle 
but also uses other build tools such as Apache Maven, Apache Ant, GNU 
Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and 
even Windows batch files. It runs on Linux, macOS, and Windows, and 
supports eight different hardware architectures (last time I counted).

Testing requires you to con?gure and run hundreds (!) of these complex 
builds and unit tests on multiple systems under Linux, macOS, and Windows.

I'm tempted to say that having (almost) reproducible builds in JavaFX 
would help in verifying that you're creating the same artifacts before 
and after, but there are just so many artifacts to verify. It's not one 
build that produces a set of artifacts. Rather, it's multiple builds 
that produce multiple sets of artifacts on multiple systems.

> And I would need to know if there are some non-obvious out-of-tree features that need special handling.

Almost everything in it needs special handling.

> I can understand if you would be wary about this proposal; I may not be able to complete the transition from the current to a new build.

I think you're looking at a multi-year project.

John


From philip.race at oracle.com  Tue May 27 19:55:43 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 27 May 2025 12:55:43 -0700
Subject: Build logic renovation?
In-Reply-To: <fc572df1-b083-4d08-af90-7a61519edc5a@status6.com>
References: <ORGyUxQ--F-9@mada.dk>
 <fc572df1-b083-4d08-af90-7a61519edc5a@status6.com>
Message-ID: <c6e00ea6-7809-4de1-a10a-e00b30d80830@oracle.com>

I am with John that the direction we should invest in is the path Johan 
suggested, and give it our best shot.
A build system isn't just "done once". It is a continual maintenance task.
And if we can largely leverage the work done for JDK it will mean 
savings all round, now and in the future.

-phil.

On 5/27/25 12:27 PM, John Neffenger wrote:
> Hi, Jesper. My comments below are not meant to discourage you entirely 
> from your plans -- really! :-) -- but rather to help you understand, 
> based on my own experience, the scope of the work involved.
>
> On 5/27/25 6:41 AM, Jesper Skov wrote:
>> Would there be interest in reworking the build logic?
>
> Yes, but perhaps more like this:
>
> Building OpenJFX using JDK
> https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
>
>> All the procedural Gradle in one large file makes it hard to 
>> understand the build logic.
>
> Indeed.
>
>> It looks very complex.
>
> It is very complex.
>
>> And it may be performing below optimum (this is just a conjecture).
>
> Without a doubt.
>
>> I know that the current build is very obviously working.
>
> Barely. :-)
>
>> And that there may good reasons to keep it in its current form.
>
> No, not really, except for the "very obviously working" part.
>
>> But if there is an interest, I would like to make the build more 
>> idiomatic Gradle.
>
> Personally, I'm done with Gradle for any of my own projects. It's 
> difficult to pin down precisely the way in which Gradle fails to be a 
> good build system, but I think Bruce Eckel summarized it best in his 
> article below:
>
> Jan 2, 2021 - 16 minute read
> The Problem with Gradle
> https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
>
>> Changing the build would be an explorative and iterative task.
>
> The JavaFX build system is remarkably complicated. It is based on 
> Gradle but also uses other build tools such as Apache Maven, Apache 
> Ant, GNU Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual 
> Studio, and even Windows batch files. It runs on Linux, macOS, and 
> Windows, and supports eight different hardware architectures (last 
> time I counted).
>
> Testing requires you to con?gure and run hundreds (!) of these complex 
> builds and unit tests on multiple systems under Linux, macOS, and 
> Windows.
>
> I'm tempted to say that having (almost) reproducible builds in JavaFX 
> would help in verifying that you're creating the same artifacts before 
> and after, but there are just so many artifacts to verify. It's not 
> one build that produces a set of artifacts. Rather, it's multiple 
> builds that produce multiple sets of artifacts on multiple systems.
>
>> And I would need to know if there are some non-obvious out-of-tree 
>> features that need special handling.
>
> Almost everything in it needs special handling.
>
>> I can understand if you would be wary about this proposal; I may not 
>> be able to complete the transition from the current to a new build.
>
> I think you're looking at a multi-year project.
>
> John
>


From pavelturk2000 at gmail.com  Wed May 28 10:10:36 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 28 May 2025 13:10:36 +0300
Subject: CodeArea: request to raise priority of JDK-8357405 (text length
 metrics for ContentChange)
In-Reply-To: <CY8PR10MB72656DE7D085707CE16310B4E564A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <8d32334e-cb6e-4d62-9138-a917a8549ecc@gmail.com>
 <CY8PR10MB72656DE7D085707CE16310B4E564A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <fb364dba-39cf-4c58-828e-2a56a0110f80@gmail.com>

Andy, thank you for your reply.

When making changes, I think we have THREE key parameters:

1. startByte ? this is the offset in the file where the change begins. If the document is very large, this value might require a long, although that would be one case in a billion.
2. removedLength ? the length of the removed chunk of text starting from startByte. I think this will always fit in an int, but it could be a long as well. At the same time String#length() -> int.
3. insertedLength ? the length of the inserted text starting at startByte. Again, I believe int should suffice, but long is also an option.

Now, in JDK-8357405, only (2) and (3) are mentioned. So, the calculation of startByte is left for the future or for the user to handle. The reason for this is that the user can compute startByte themselves, but they cannot efficiently determine removedLength and insertedLength (at least I don?t know how).

At the same time, I believe that during the change processing, the library itself can quite easily calculate these values and include them in the ContentChange. For example, when a portion of text is selected and replaced with something else, the library knows:
a) the length of the selected text, and
b) the length of the inserted text.

If I?m wrong and the user can efficiently calculate removedLength and insertedLength using a custom model, could you explain how to do that? Because without this data, my work with JFX CodeArea is completely blocked.

At the same time, wouldn?t it be better to support these values out of the box? Many code analysis libraries rely on them, and CodeArea is intended to be integrated with exactly those kinds of libraries.

Best regards, Pavel

On 5/27/25 20:51, Andy Goryachev wrote:
>
> Dear Pavel:
>
> This is not a trivial request.? Currently, there is not easy way to control (override) the behavior of the CodeModel with respect to line endings.? Line endings are not stored in the model, but they are emitted when saving/copying.
>
> Perhaps we ought to add a dedicated property to the model (line endings: CR/LF/CRLF/PLATFORM?) which would allow the application to specify the behavior and allow the model to perform the offset calculations.
>
> The other issue is that the CodeArea supports large models (CodeTextModel with a custom BasicTextModel.Content). Computing offsets in a large model not only may take a long time, but also produce result that does not fit into 31 bits.? Which means, for all intents and purposes, this functionality should be implemented by a custom model.
>
> What do you think?
>
> Cheers,
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Thursday, May 22, 2025 at 05:29
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *CodeArea: request to raise priority of JDK-8357405 (text length metrics for ContentChange)
>
> I'd like to kindly ask for consideration in raising the priority of JDK-8357405 about adding text length
> metrics to ContentChange for removed/inserted text for CodeArea.
>
> The reason for this request is that accurate and reliable information about text changes is essential
> when integrating CodeArea with code processing libraries. Currently, CodeArea does not provide
> such information.
>
> As a result, CodeArea can only be reliably used in read-only mode at the moment ? which severely
> limits its applicability in real-world applications.
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250528/82d1b8f4/attachment.htm>

From zelmidaoui at openjdk.org  Wed May 28 11:26:57 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 28 May 2025 11:26:57 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
 [v4]
In-Reply-To: <mYTOiBzaaSM5mCTXpmUB30I4KhIcbW1EcOWI36fXFEI=.a846fbc7-8e22-48ae-a43d-32c6efc051d5@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
 <mYTOiBzaaSM5mCTXpmUB30I4KhIcbW1EcOWI36fXFEI=.a846fbc7-8e22-48ae-a43d-32c6efc051d5@github.com>
Message-ID: <uLivti_AaM9VpRkaU7TDiZAVSOA3TMO8zAawIjVfwT0=.57b01958-410f-4902-a9dc-e26acd4c9ed3@github.com>

On Tue, 27 May 2025 16:09:52 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> When the Root TreeItem is set to null, need to relayout to show the children items
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor change : new line added

@arapte Could you please review ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2915950640

From mstrauss at openjdk.org  Wed May 28 13:59:13 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 28 May 2025 13:59:13 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v71]
In-Reply-To: <g5dz3qyuvnkQPwlmWiFeP-IFyryk-qkTpaGEJlykz2k=.7a0536ac-3953-471e-983a-37675c132ee2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <utcEc7VKyHrTiODKZVrI41l1ZJ-_T_YXhzrEw9p361g=.b01c5268-c5d9-4f76-bbde-9819d3a73ab2@github.com>
 <g5dz3qyuvnkQPwlmWiFeP-IFyryk-qkTpaGEJlykz2k=.7a0536ac-3953-471e-983a-37675c132ee2@github.com>
Message-ID: <QvP5cMgnX3H6PG-ayrzoyHuyA5eNdy9bROsmaBWUx7Q=.f657860b-1526-4e84-bf9e-8f9854158189@github.com>

On Fri, 2 May 2025 18:45:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify header area picking
>
> The API looks good to me. I want to do a second pass over the javadocs once I have time to try a few things, but I doubt I'll request any significant changes.
> 
> Go ahead and create the CSR when you are ready.

@kevinrushforth @andy-goryachev-oracle @drmarmac 
This PR seems to be idling at 99%. Can we get it across the finish line?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2916457396

From mmack at openjdk.org  Wed May 28 14:11:17 2025
From: mmack at openjdk.org (Markus Mack)
Date: Wed, 28 May 2025 14:11:17 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75]
In-Reply-To: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>
Message-ID: <x7WmdCTQzuBJ1_w40wHDEf2Mw4UDaCg0b-AF523I6ss=.c56d3fb4-ab97-4f1f-b267-65b888195e8d@github.com>

On Tue, 20 May 2025 19:01:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into feature/extended-window
>  - javadoc
>  - Merge branch 'master' into feature/extended-window
>  - reapply overlay CSS
>  - Merge branch 'master' into feature/extended-window
>  - simplify header area picking
>  - Fix top resize border on Windows
>  - Merge branch 'master' into feature/extended-window
>  - doc change
>  - add HeaderDragType
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/a14c2b33...dcbb68d0

All changes since my previous review look good.

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

Marked as reviewed by mmack (Author).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2875266963

From angorya at openjdk.org  Wed May 28 14:43:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 May 2025 14:43:03 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <-3mhsrrjG8RUteSRHsQMyzFj3J46X7AcMXp857S99_k=.bee69ba4-53f3-4f4d-a421-72c2ac58fe5e@github.com>

On Mon, 28 Apr 2025 18:27:37 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
>> 
>> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
>> 
>> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
>> 
>> | isPopupTriggered on: | Windows  | macOS | Linux |
>> | ------------- | ------------- | ------------- | ------------- |
>> | mousePressed  | false  | true | true |
>> | mouseReleased  | true  | false | false?|
>> 
>> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
>> 
>>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
>> 
>> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
>> 
>> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.
>
> Jose Pereda 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

This PR is ready to integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2916601871

From angorya at openjdk.org  Wed May 28 14:50:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 May 2025 14:50:14 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75]
In-Reply-To: <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>
Message-ID: <NFLoHHZbe5ZXQ6XA4knLaaq8m2ciV--efu_UK58_UEY=.52eee4e2-86a2-4ea1-a37e-17ab3f6d3f0a@github.com>

On Tue, 20 May 2025 19:01:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'master' into feature/extended-window
>  - javadoc
>  - Merge branch 'master' into feature/extended-window
>  - reapply overlay CSS
>  - Merge branch 'master' into feature/extended-window
>  - simplify header area picking
>  - Fix top resize border on Windows
>  - Merge branch 'master' into feature/extended-window
>  - doc change
>  - add HeaderDragType
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/a14c2b33...dcbb68d0

Does the CSR need to be updated?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2875405978

From jpereda at openjdk.org  Wed May 28 14:57:59 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 28 May 2025 14:57:59 GMT
Subject: Integrated: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
Message-ID: <LlpXpAThlUZv0lKoVPJcc0Xl6UmqQY0VXaDxfUqCKHM=.8a9eefe0-65ea-41f3-b4e0-489c1b335a70@github.com>

On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Note: The JBS issue [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux, but it happens on macOS too. 
> 
> When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
> 
> Currently, `TableColumnHeader#mouseReleasedHandler` checks for `MouseEvent::isPopupTriggered`, but it doesn't have a check on `mousePressed`. However,  it can be seen that a right click on the header has the following values for `MouseEvent:: isPopupTriggered` on the different platforms and mouse pressed and released events:
> 
> | isPopupTriggered on: | Windows  | macOS | Linux |
> | ------------- | ------------- | ------------- | ------------- |
> | mousePressed  | false  | true | true |
> | mouseReleased  | true  | false | false?|
> 
> Also, the JavaDoc for `MouseEvent::isPopupTriggered` clearly states that:
> 
>> **Note**: Popup menus are triggered differently on different systems. Therefore, `popupTrigger` should be checked in both `onMousePressed` and `mouseReleased` for proper cross-platform functionality.
> 
> Therefore, this PR adds a check to `MouseEvent::isPopupTrigger` in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.
> 
> Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.

This pull request has now been integrated.

Changeset: 7e8eff99
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7e8eff9983764ee4a896e0748ae357718297d5be
Stats:     199 lines in 2 files changed: 195 ins; 0 del; 4 mod

8207333: [Linux, macOS] Column sorting is triggered always after context menu request on table header

Reviewed-by: angorya, zelmidaoui

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

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

From mstrauss at openjdk.org  Wed May 28 15:10:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 28 May 2025 15:10:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar (Preview) [v75]
In-Reply-To: <NFLoHHZbe5ZXQ6XA4knLaaq8m2ciV--efu_UK58_UEY=.52eee4e2-86a2-4ea1-a37e-17ab3f6d3f0a@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <3X1xrvS3Nsr-E1_BjVrJHWs7S2FwzCnYcjMmfMK6LZQ=.5d7a3eb8-ab94-4d2f-a9e2-6cb3704154dc@github.com>
 <NFLoHHZbe5ZXQ6XA4knLaaq8m2ciV--efu_UK58_UEY=.52eee4e2-86a2-4ea1-a37e-17ab3f6d3f0a@github.com>
Message-ID: <48PPrMi7tZa4pmvvyX-0jGLGtw5KXUrUdhg-zMyCqrM=.6a8fb67d-3801-4688-8de9-dd22d605114f@github.com>

On Wed, 28 May 2025 14:47:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Does the CSR need to be updated?

Good point, yes. I've updated the CSR, clarifying that the `HeaderBar` constructor arguments can be `null`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2916697124

From arapte at openjdk.org  Wed May 28 15:51:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 28 May 2025 15:51:59 GMT
Subject: RFR: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows [v2]
In-Reply-To: <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
 <L2ODCg3xVXirWbB2pjt6z1etf09b1h4BW1bVGNejJl8=.813ad4e8-e04a-49f7-842b-b90ac0530eed@github.com>
Message-ID: <0QADnjQ3A43UgVDkHGW58LBlB1dcKQd9zxS-Vypjx-A=.e2d60ae1-d89b-4acf-8018-5920f797322a@github.com>

On Thu, 22 May 2025 16:53:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
>> 
>> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
>> 
>> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Merge remote-tracking branch 'upstream/master' into 8354986-vs2022-17.13.2
>  - Only define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' for ICU on Windows
>  - Define '_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR' when compiling web (ICU), graphics, and media
>  - 8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1807#pullrequestreview-2875617415

From kcr at openjdk.org  Wed May 28 16:27:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 May 2025 16:27:03 GMT
Subject: Integrated: 8354986: Update to Visual Studio 2022 version 17.13.2 on
 Windows
In-Reply-To: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
References: <BeiGZ94L_qNhaVgZ8vy4S9Kky3Jr4OMF0apLwcdeXK8=.0260bedf-dd6e-40ea-8992-43644ae8f099@github.com>
Message-ID: <yRILkQKPBOO7WEMToO409HCb0KjiTodBfjrNz0hCKk0=.f2babfbe-f1a0-4c4a-9bce-ebf0d7c7e159@github.com>

On Wed, 14 May 2025 23:20:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.13.2 (from 17.6.5) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit. All tests pass.
> 
> NOTE: There is a compatibility issue, introduced in VS 2022 17.10, that is seen when compiling with a more recent version of Visual Studio and running against an older `msvcp140.dll`. A workaround is documented in the [VS 2022 17.10 release notes](https://github.com/microsoft/STL/releases/tag/vs-2022-17.10) and is implemented by this PR. Without the workaround of compiling with `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` WebKit crashes in the ICU library when run on JDK 24 or earlier, since the version of `msvcp140.dll` in JDK 24 is the one from 17.6.5 (the JDK loads its `msvcp140.dll` first, causing the one we redistribute to be ignored). With this workaround, we can run both on older JDKs and on JDK 25.

This pull request has now been integrated.

Changeset: a1c5b1c1
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a1c5b1c14130d91aa8d52eecfb1b667e98d5c583
Stats:     21 lines in 14 files changed: 17 ins; 0 del; 4 mod

8354986: Update to Visual Studio 2022 version 17.13.2 on Windows

Reviewed-by: almatvee, arapte, sykora

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

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

From arapte at openjdk.org  Wed May 28 18:06:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 28 May 2025 18:06:57 GMT
Subject: RFR: 8356983: Create implementation of NSAccessibilityImage
 protocol
In-Reply-To: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
References: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
Message-ID: <fsGMrBoycMhq3dmVXIOd55WW14GuGDoW1gGbcuBFlXs=.6618b1d7-d79d-4f2e-a700-e656e8754b44@github.com>

On Tue, 27 May 2025 04:18:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Initial implementation;
> - Added accessible text to image view in Ensemble8 to make testing of this feature with Ensemble8 more viable;

LGTM...

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1816#pullrequestreview-2875986483

From duke at openjdk.org  Wed May 28 19:39:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 19:39:58 GMT
Subject: RFR: 8356983: Create implementation of NSAccessibilityImage
 protocol
In-Reply-To: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
References: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
Message-ID: <2AMqNhxWhQmpcNCq380dsvUfv_-8S9Tj0CPVDrmEd-c=.e56d30a0-cdf0-4356-abfb-cf60c6dab14e@github.com>

On Tue, 27 May 2025 04:18:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Initial implementation;
> - Added accessible text to image view in Ensemble8 to make testing of this feature with Ensemble8 more viable;

@azuev-java 
Your change (at version 26ab7447ada7bcadfdc23e5b507068ebad22fc21) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1816#issuecomment-2917410365

From kizune at openjdk.org  Wed May 28 19:44:01 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 28 May 2025 19:44:01 GMT
Subject: Integrated: 8356983: Create implementation of NSAccessibilityImage
 protocol
In-Reply-To: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
References: <tNefGEkxs9qryyfNSg143qKSE7piMvahMrn4ZnW4xNw=.00de2b93-f7fb-4931-bb6b-617554c2046a@github.com>
Message-ID: <Dz1gITwPogxNrwgyAx6GKYLb1D1i2cuBKL9rUcP34IA=.30ea5170-b350-4186-979a-00139bca3bd7@github.com>

On Tue, 27 May 2025 04:18:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Initial implementation;
> - Added accessible text to image view in Ensemble8 to make testing of this feature with Ensemble8 more viable;

This pull request has now been integrated.

Changeset: 5d367530
Author:    Alexander Zuev <kizune at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5d3675308865c6e1cefc4978557165939566f01f
Stats:     93 lines in 4 files changed: 91 ins; 0 del; 2 mod

8356983: Create implementation of NSAccessibilityImage protocol

Reviewed-by: angorya, arapte

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

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

From kevin.rushforth at oracle.com  Wed May 28 19:51:24 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 28 May 2025 12:51:24 -0700
Subject: CFV: New OpenJFX Committer: Alexander Zuev
Message-ID: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>

I hereby nominate Alexander Zuev [1] to OpenJFX Committer.

Alexander is a member of the JavaFX team at Oracle who has contributed 
10 commits [2] to OpenJFX.

Votes are due by June 11, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project 
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#kizune

[2] 
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer


From kevin.rushforth at oracle.com  Wed May 28 19:52:09 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 28 May 2025 12:52:09 -0700
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <ee2b2344-f488-42c7-a247-c151c4732668@oracle.com>

Vote: YES

--Kevin

On 5/28/2025 12:51 PM, Kevin Rushforth wrote:
> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.

From andy.goryachev at oracle.com  Wed May 28 19:53:00 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 28 May 2025 19:53:00 +0000
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <CY8PR10MB726510EA724A2DE7BEE8B4DDE567A@CY8PR10MB7265.namprd10.prod.outlook.com>

Vote: YES

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Wednesday, May 28, 2025 at 12:51
To: openjfx-dev <openjfx-dev at openjdk.org>, Alexander Zuev <alexander.zuev at oracle.com>
Subject: CFV: New OpenJFX Committer: Alexander Zuev
I hereby nominate Alexander Zuev [1] to OpenJFX Committer.

Alexander is a member of the JavaFX team at Oracle who has contributed
10 commits [2] to OpenJFX.

Votes are due by June 11, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#kizune

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250528/feba3606/attachment.htm>

From johan at lodgon.com  Wed May 28 19:56:30 2025
From: johan at lodgon.com (Johan Vos)
Date: Wed, 28 May 2025 21:56:30 +0200
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <CAK7C+XjiMcfiZYLCXUoUkhtv_kfL=TCroJ+-kdJ05W+SpJ7f=Q@mail.gmail.com>

Vote: YES

- Johan

Op wo 28 mei 2025 om 21:51 schreef Kevin Rushforth <
kevin.rushforth at oracle.com>:

> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.
>
> Alexander is a member of the JavaFX team at Oracle who has contributed
> 10 commits [2] to OpenJFX.
>
> Votes are due by June 11, 2025 at 20:00 UTC.
>
> Only current OpenJFX Committers [3] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [4]. Nomination to a project
> Committer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#kizune
>
> [2]
>
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits
>
> [3] https://openjdk.org/census#openjfx
>
> [4] https://openjdk.org/bylaws#lazy-consensus
>
> [5] https://openjdk.org/projects#project-committer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250528/920fda31/attachment.htm>

From philip.race at oracle.com  Wed May 28 20:20:47 2025
From: philip.race at oracle.com (Philip Race)
Date: Wed, 28 May 2025 13:20:47 -0700
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <2743b379-6604-4a8d-b56d-ef0efb4bc4ff@oracle.com>

Vote: yes

-phil.

From tsayao at openjdk.org  Wed May 28 20:38:18 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 28 May 2025 20:38:18 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v23]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <eoUlSSOFnI0PZrdlMZZPezoHSN7nmdlsv-RvAifMvL4=.127f8df9-d519-407c-8bc3-3253e2054db2@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' into 8354943
 - Merge remote-tracking branch 'origin/8354943' into 8354943
 - Merge branch 'master' into 8354943
 - Fix debug value
 - Merge branch 'master' into 8354943
 - - Fixes on TestStage
 - - Review fixes
   - Fix Focus
   - Improvements on TestStage to assist testing
 - Merge branch 'master' into 8354943
 - Fix non-debug build
 - Review fixes
 - ... and 17 more: https://git.openjdk.org/jfx/compare/5d367530...fe5073f5

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=22
  Stats: 4135 lines in 28 files changed: 2881 ins; 749 del; 505 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Wed May 28 21:08:15 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 28 May 2025 21:08:15 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v24]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <eCNbi27fhaQEj3aClLfSnk66IKOEPZRTYT1MdMPzYRU=.28322f86-c197-4d5c-80eb-ad4eb50cc541@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Always report new size (for Kwin)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/fe5073f5..36c57e15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=22-23

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From jskov at mada.dk  Thu May 29 05:20:05 2025
From: jskov at mada.dk (Jesper Skov)
Date: Thu, 29 May 2025 07:20:05 +0200 (GMT+02:00)
Subject: Build logic renovation?
In-Reply-To: <fc572df1-b083-4d08-af90-7a61519edc5a@status6.com>
References: <ORGyUxQ--F-9@mada.dk>
 <fc572df1-b083-4d08-af90-7a61519edc5a@status6.com>
Message-ID: <ORPTvT3--F-9@mada.dk>

Ah, good insight!

Sounds like a renovation of the Gradle file is not really a move forward then.
Cheers!
Jesper

May 27, 2025, 21:29 by john at status6.com:

> Hi, Jesper. My comments below are not meant to discourage you entirely from your plans -- really! :-) -- but rather to help you understand, based on my own experience, the scope of the work involved.
>
> On 5/27/25 6:41 AM, Jesper Skov wrote:
>
>> Would there be interest in reworking the build logic?
>>
>
> Yes, but perhaps more like this:
>
> Building OpenJFX using JDK
> https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
>
>> All the procedural Gradle in one large file makes it hard to understand the build logic.
>>
>
> Indeed.
>
>> It looks very complex.
>>
>
> It is very complex.
>
>> And it may be performing below optimum (this is just a conjecture).
>>
>
> Without a doubt.
>
>> I know that the current build is very obviously working.
>>
>
> Barely. :-)
>
>> And that there may good reasons to keep it in its current form.
>>
>
> No, not really, except for the "very obviously working" part.
>
>> But if there is an interest, I would like to make the build more idiomatic Gradle.
>>
>
> Personally, I'm done with Gradle for any of my own projects. It's difficult to pin down precisely the way in which Gradle fails to be a good build system, but I think Bruce Eckel summarized it best in his article below:
>
> Jan 2, 2021 - 16 minute read
> The Problem with Gradle
> https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
>
>> Changing the build would be an explorative and iterative task.
>>
>
> The JavaFX build system is remarkably complicated. It is based on Gradle but also uses other build tools such as Apache Maven, Apache Ant, GNU Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and even Windows batch files. It runs on Linux, macOS, and Windows, and supports eight different hardware architectures (last time I counted).
>
> Testing requires you to con?gure and run hundreds (!) of these complex builds and unit tests on multiple systems under Linux, macOS, and Windows.
>
> I'm tempted to say that having (almost) reproducible builds in JavaFX would help in verifying that you're creating the same artifacts before and after, but there are just so many artifacts to verify. It's not one build that produces a set of artifacts. Rather, it's multiple builds that produce multiple sets of artifacts on multiple systems.
>
>> And I would need to know if there are some non-obvious out-of-tree features that need special handling.
>>
>
> Almost everything in it needs special handling.
>
>> I can understand if you would be wary about this proposal; I may not be able to complete the transition from the current to a new build.
>>
>
> I think you're looking at a multi-year project.
>
> John
>


From prasanta.sadhukhan at oracle.com  Thu May 29 06:25:01 2025
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 29 May 2025 11:55:01 +0530
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <80f4e7ae-61ab-452d-8ede-4a8befa545f8@oracle.com>

Vote: Yes

Regards
Prasanta
On 29-05-2025 01:21, Kevin Rushforth wrote:
> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.
>
> Alexander is a member of the JavaFX team at Oracle who has contributed 
> 10 commits [2] to OpenJFX.
>
> Votes are due by June 11, 2025 at 20:00 UTC.
>
> Only current OpenJFX Committers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [4]. Nomination to a 
> project Committer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#kizune
>
> [2] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits
>
> [3] https://openjdk.org/census#openjfx
>
> [4] https://openjdk.org/bylaws#lazy-consensus
>
> [5] https://openjdk.org/projects#project-committer
>

From ajit.ghaisas at oracle.com  Thu May 29 08:21:50 2025
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 29 May 2025 08:21:50 +0000
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <F183F7DD-4B49-46D2-800F-34D0F20A2036@oracle.com>

Vote : YES

Regards,
Ajit

> On 29 May 2025, at 1:21?AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.
> 
> Alexander is a member of the JavaFX team at Oracle who has contributed 10 commits [2] to OpenJFX.
> 
> Votes are due by June 11, 2025 at 20:00 UTC.
> 
> Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.org/census#kizune
> 
> [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits
> 
> [3] https://openjdk.org/census#openjfx
> 
> [4] https://openjdk.org/bylaws#lazy-consensus
> 
> [5] https://openjdk.org/projects#project-committer
> 


From mstrauss at openjdk.org  Thu May 29 15:42:48 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 29 May 2025 15:42:48 GMT
Subject: RFR: 8345348: CSS media feature queries [v26]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <NhvA-Cu1sni0jXc0rC6S0sBgKkIwmLOrV614rOj76aA=.1557185f-8fe7-4d9f-b417-07e9d1d4f8fb@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:

  move doc from Scene.Preferences to Platform.Preferences

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/b61f1918..4c5dbc4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=25
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=24-25

  Stats: 126 lines in 2 files changed: 48 ins; 70 del; 8 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  Thu May 29 15:47:20 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 29 May 2025 15:47:20 GMT
Subject: RFR: 8345348: CSS media feature queries [v27]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <8J82wwQko11-toLs4WDZii_ah2_97_0LPvNGsZ6IEMc=.eefcaf40-d263-402f-9e56-e1edf97af454@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:

  reorder Scene.Preferences.colorScheme

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/4c5dbc4c..6229a69e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=26
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=25-26

  Stats: 28 lines in 1 file changed: 14 ins; 14 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  Thu May 29 15:58:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 May 2025 15:58:04 GMT
Subject: RFR: 8345348: CSS media feature queries [v27]
In-Reply-To: <8J82wwQko11-toLs4WDZii_ah2_97_0LPvNGsZ6IEMc=.eefcaf40-d263-402f-9e56-e1edf97af454@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <8J82wwQko11-toLs4WDZii_ah2_97_0LPvNGsZ6IEMc=.eefcaf40-d263-402f-9e56-e1edf97af454@github.com>
Message-ID: <d_a0meUm8lFt4-VhLzT2RcWOCF5_BP1uHw4xOcLq2YI=.3e40e325-ae29-412d-bfad-6a7065c6b8c3@github.com>

On Thu, 29 May 2025 15:47:20 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:
> 
>   reorder Scene.Preferences.colorScheme

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2878794065

From dlemmermann at gmail.com  Thu May 29 16:23:13 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Thu, 29 May 2025 18:23:13 +0200
Subject: Font Weights
Message-ID: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>

Hi everyone,

Is there any chance we can get font weight working properly so that I can use a font with medium boldness and use it by declaring: -fx-font-weight: bolder; or by declaring -fx-font-weight: 600;? I know I can work around it by using the font family name, e.g. ?Rubik Medium? but this makes it impossible to replace the font at runtime, which is a requirement I am facing right now in order to support users with dyslexia. I was also considering using a variable but this is not supported for font family names (e,g, ?-my-font; ?Rubik Medium?).

Any other work arounds I am missing?

Dirk


From john.hendrikx at gmail.com  Thu May 29 18:03:55 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 29 May 2025 20:03:55 +0200
Subject: Font Weights
In-Reply-To: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>
References: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>
Message-ID: <af4bd032-359d-43ef-8df5-81a878bb589c@gmail.com>


On 29/05/2025 18:23, Dirk Lemmermann wrote:
> Hi everyone,
>
> Is there any chance we can get font weight working properly so that I can use a font with medium boldness and use it by declaring: -fx-font-weight: bolder; or by declaring -fx-font-weight: 600;? I know I can work around it by using the font family name, e.g. ?Rubik Medium? but this makes it impossible to replace the font at runtime, which is a requirement I am facing right now in order to support users with dyslexia. I was also considering using a variable but this is not supported for font family names (e,g, ?-my-font; ?Rubik Medium?).
Just curious, how would a variable help here for the problem having the
font selectable at runtime?
> Any other work arounds I am missing?

I don't have any easy solutions here, and I'm unsure what is involved in
actually making -fx-font-weight work better.

So,?all I can offer is something very ugly like having the user select a
font, then generating a CSS file, and setting that on the root node; if
you keep the styles for font selection separate it may be doable as
you'd probably could get away with just replacing a single stylesheet
then (ie. mark a TextField with ".font-large" specifically and define
what that means in the custom CSS file).? This is a bit anti-CSS as
you'd prefer to mark such nodes only with their intended function, and
determine a suitable font based on that, but styles in FX don't compose.

If you're willing to go in the direction of generating all CSS files
based on LESS or SCSS (at runtime mind you, I hate doing this during a
build), more is possible:

What I've been doing myself (although I don't allow runtime selection)
is to allow users to modify CSS files; using?LESS or SCSS one can neatly
pack all font related stuff into a single file, so I've sort of solved
this by having a `fonts.less` (see below).? I then mark styles with one
of the custom styles (.light, .regular, etc) to indicate what final font
they'll be using.? However, to make this work even at run time, I'd have
to regenerate all derived CSS files (but as I said, I can do this at
runtime anyway) -- so the effort is in then primarily in auto-generating
a base fonts CSS file given some user selection, then replacing all
stylesheets that were set throughout the application (or just?restarting
the application).

For now a user could?do this manually by only editing `fonts.less` and
then (re)starting the application.

Here is the fonts.less file I was talking about (note: there is also a
Linux variant as fonts work differently on different platforms as
well... perhaps MacOS needs a modified one also, but I never tried there)

fonts.less:

/*

* The Noto Sans font supports many variations. To get the correct variation

* in JavaFX, select them as follows:

*

* - Black = Noto Sans Blk

* - Bold = Noto Sans + font-weight: bold

* - Semi Bold = Noto Sans SemBd

* - Medium = Noto Sans Med

* - Regular = Noto Sans + font-weight: normal

* - Light = Noto Sans Light

*

* Note that these names are for Windows. Other platforms can use

* slightly different names.

*/

.light {

-fx-font-family: "Noto Sans Light";

-fx-font-weight: normal;

}

.regular {

-fx-font-family: "Noto Sans";

-fx-font-weight: normal;

}

.medium {

-fx-font-family: "Noto Sans Med";

-fx-font-weight: bold;

}

.semi-bold {

-fx-font-family: "Noto Sans SemBd";

-fx-font-weight: bold;

}

.bold {

-fx-font-family: "Noto Sans";

-fx-font-weight: bold;

}

.black {

-fx-font-family: "Noto Sans Blk";

-fx-font-weight: bold;

}

fonts-linux.less:

.light { -fx-font-family: "Noto Sans Light"; -fx-font-weight: normal; }
.regular { -fx-font-family: "Noto Sans"; -fx-font-weight: normal; }
.medium { -fx-font-family: "Noto Sans Medium"; -fx-font-weight: normal;
} .semi-bold { -fx-font-family: "Noto Sans SemiBold"; -fx-font-weight:
normal; } .bold { -fx-font-family: "Noto Sans"; -fx-font-weight: bold; }
.black { -fx-font-family: "Noto Sans Black"; -fx-font-weight: normal; }
And using it for some arbitrary style is then done (also with LESS) like:

.style-p3-extra-light {

-fx-font-size: 15;

.light;

}

Not what you hoped for I think :)

--John

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

From tsayao at openjdk.org  Thu May 29 18:14:59 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 29 May 2025 18:14:59 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v24]
In-Reply-To: <eCNbi27fhaQEj3aClLfSnk66IKOEPZRTYT1MdMPzYRU=.28322f86-c197-4d5c-80eb-ad4eb50cc541@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <eCNbi27fhaQEj3aClLfSnk66IKOEPZRTYT1MdMPzYRU=.28322f86-c197-4d5c-80eb-ad4eb50cc541@github.com>
Message-ID: <MQc9NVvdhVGfSQxeWXrR6yBmPizt24lLsGRbGA6djk4=.7bec7901-2c6f-4cb0-90e2-78c175d7db1f@github.com>

On Wed, 28 May 2025 21:08:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
>> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is provided:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/brow...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Always report new size (for Kwin)

I now own a mac mini m4 so I can test on mac. Still scared of building on windows :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2920192196

From tsayao at openjdk.org  Thu May 29 18:15:00 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 29 May 2025 18:15:00 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v18]
In-Reply-To: <6ucekCPrcMemDlS4jN3rM-JieyN92vEO0X_jXsi4NU8=.1b499a0f-0b02-4ebf-b5c6-2784a3c468f3@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <vPv1AdWdQD9-uEaTmOHdAJgsvPzXBoiEKecmCQjDXIA=.25599a6a-e4dd-4b41-8906-dc7f9ca18e3c@github.com>
 <sU7ge5ljD7d7ARHCV8svfG7a4bBWzSpft39sAiiZKLg=.300dec93-eb9c-4168-b483-adba2707e6e8@github.com>
 <L9-3ji8_o1Yb7pgMVpwiPSxleVKaLv2UaRe2ADBM7y4=.f7b1d92a-33f0-4359-83c5-6d9913054681@github.com>
 <LzCrUfxy8DGXhWWZFCe_4WCKBEL_ks1p7r-A6zV7zqk=.7223b29c-263d-4ccf-86a5-67195f90200c@github.com>
 <-e3004pK5tFoHDR7S3hjMZPsMJT_eeBZbdqmJKM3kwM=.3f338f03-26d1-4f7e-ae63-73a3537127df@github.com>
 <6ucekCPrcMemDlS4jN3rM-JieyN92vEO0X_jXsi4NU8=.1b499a0f-0b02-4ebf-b5c6-2784a3c468f3@github.com>
Message-ID: <fG8hpEQ3WM3SmQ2DtxgZ0yCNYxkEEfrMTjLyMtbSeWk=.7f0066ad-14e0-4a89-a535-fbff23a930f4@github.com>

On Sun, 11 May 2025 12:20:55 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Sorry, my bad, you're right. I now hide in shame..
>
> Fixed it.

Those tests aren't ok, I will redo it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2114495737

From michaelstrau2 at gmail.com  Thu May 29 18:31:52 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 29 May 2025 20:31:52 +0200
Subject: CSS roadmap proposal
Message-ID: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>

Here is how I think we should be evolving JavaFX CSS over the next
period of time:

1. Media queries
Gist: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7
PR: https://github.com/openjdk/jfx/pull/1655

This feature is already out for review.

2. System colors
Gist: https://gist.github.com/mstr2/afac42ab9587c1040a6cf7b091cee99f

System colors allow stylesheet authors to use colors that are defined
by the scene or the platform. Most notably, this includes the accent
color. We will also add new media queries to help stylesheet authors
deal with contrast modes.

3. With media queries and system colors in place, we can remove the
built-in high contrast stylesheets that come with Caspian and Modena.
Instead of hard-coding these special cases (and not even in a good
way), we can now use standard APIs to achieve a better result. This
will remove a big chunk of special-casing from the codebase and bring
us closer to an equal playing field of built-in vs. third-party
themes.

4. Dark Modena / Modena 2025?

5. Bold new theme?


What do you think? Please focus comments on step 1-3, and not on
bikeshedding a new theme.

From dlemmermann at gmail.com  Thu May 29 18:33:54 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Thu, 29 May 2025 20:33:54 +0200
Subject: Font Weights
In-Reply-To: <af4bd032-359d-43ef-8df5-81a878bb589c@gmail.com>
References: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>
 <af4bd032-359d-43ef-8df5-81a878bb589c@gmail.com>
Message-ID: <EE896AC8-C343-40F7-8B3C-78288214E3B6@gmail.com>

I think what I really want is that this feature ?simply? works as documented. I have not looked at the implementation of the font support, yet, but it feels like this shouldn?t be too hard to implement correctly. If somebody knows more about the problem I would love to hear about it.

The official JavaFX CSS reference documentation at https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/doc-files/cssref.html lists font weights (integers) as possible values:

<font-weight> The font's weight, using the following syntax:
[ normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 ]

 If this will never be supported then I think the docs need to reflect that.

Again, the main benefit of this working properly would be that applications wouldn?t have to use the workaround anymore where the font family name will be used directly in all the places where a piece of text has a different weight than the default one.

Dirk

> Am 29.05.2025 um 20:03 schrieb John Hendrikx <john.hendrikx at gmail.com>:
> 
> 
> 
> On 29/05/2025 18:23, Dirk Lemmermann wrote:
>> Hi everyone,
>> 
>> Is there any chance we can get font weight working properly so that I can use a font with medium boldness and use it by declaring: -fx-font-weight: bolder; or by declaring -fx-font-weight: 600;? I know I can work around it by using the font family name, e.g. ?Rubik Medium? but this makes it impossible to replace the font at runtime, which is a requirement I am facing right now in order to support users with dyslexia. I was also considering using a variable but this is not supported for font family names (e,g, ?-my-font; ?Rubik Medium?).
> Just curious, how would a variable help here for the problem having the font selectable at runtime?
>> Any other work arounds I am missing?
> I don't have any easy solutions here, and I'm unsure what is involved in actually making -fx-font-weight work better.
> 
> So, all I can offer is something very ugly like having the user select a font, then generating a CSS file, and setting that on the root node; if you keep the styles for font selection separate it may be doable as you'd probably could get away with just replacing a single stylesheet then (ie. mark a TextField with ".font-large" specifically and define what that means in the custom CSS file).  This is a bit anti-CSS as you'd prefer to mark such nodes only with their intended function, and determine a suitable font based on that, but styles in FX don't compose.
> 
> If you're willing to go in the direction of generating all CSS files based on LESS or SCSS (at runtime mind you, I hate doing this during a build), more is possible:
> 
> What I've been doing myself (although I don't allow runtime selection) is to allow users to modify CSS files; using LESS or SCSS one can neatly pack all font related stuff into a single file, so I've sort of solved this by having a `fonts.less` (see below).  I then mark styles with one of the custom styles (.light, .regular, etc) to indicate what final font they'll be using.  However, to make this work even at run time, I'd have to regenerate all derived CSS files (but as I said, I can do this at runtime anyway) -- so the effort is in then primarily in auto-generating a base fonts CSS file given some user selection, then replacing all stylesheets that were set throughout the application (or just restarting the application).
> 
> For now a user could do this manually by only editing `fonts.less` and then (re)starting the application.
> 
> Here is the fonts.less file I was talking about (note: there is also a Linux variant as fonts work differently on different platforms as well... perhaps MacOS needs a modified one also, but I never tried there)
> 
> fonts.less:
> 
> /*
>  * The Noto Sans font supports many variations.  To get the correct variation
>  * in JavaFX, select them as follows:
>  * 
>  * - Black      = Noto Sans Blk
>  * - Bold       = Noto Sans + font-weight: bold
>  * - Semi Bold  = Noto Sans SemBd
>  * - Medium     = Noto Sans Med
>  * - Regular    = Noto Sans + font-weight: normal
>  * - Light      = Noto Sans Light
>  *
>  * Note that these names are for Windows.  Other platforms can use
>  * slightly different names.
>  */
> 
> .light {
>   -fx-font-family: "Noto Sans Light";
>   -fx-font-weight: normal;
> }
> 
> .regular {
>   -fx-font-family: "Noto Sans";
>   -fx-font-weight: normal;
> }
> 
> .medium {
>   -fx-font-family: "Noto Sans Med";
>   -fx-font-weight: bold;
> }
> 
> .semi-bold {
>   -fx-font-family: "Noto Sans SemBd";
>   -fx-font-weight: bold;
> }
> 
> .bold {
>   -fx-font-family: "Noto Sans";
>   -fx-font-weight: bold;
> }
> 
> .black {
>   -fx-font-family: "Noto Sans Blk";
>   -fx-font-weight: bold;
> }
> 
> fonts-linux.less:
> 
> .light {
>   -fx-font-family: "Noto Sans Light";
>   -fx-font-weight: normal;
> }
> 
> .regular {
>   -fx-font-family: "Noto Sans";
>   -fx-font-weight: normal;
> }
> 
> .medium {
>   -fx-font-family: "Noto Sans Medium";
>   -fx-font-weight: normal;
> }
> 
> .semi-bold {
>   -fx-font-family: "Noto Sans SemiBold";
>   -fx-font-weight: normal;
> }
> 
> .bold {
>   -fx-font-family: "Noto Sans";
>   -fx-font-weight: bold;
> }
> 
> .black {
>   -fx-font-family: "Noto Sans Black";
>   -fx-font-weight: normal;
> }
> 
> And using it for some arbitrary style is then done (also with LESS) like:
> 
> .style-p3-extra-light {
>   -fx-font-size: 15;
>   .light;
> }
> 
> Not what you hoped for I think :)
> 
> --John
> 
>> 
>> Dirk
>> 

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

From angorya at openjdk.org  Thu May 29 18:42:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 May 2025 18:42:10 GMT
Subject: RFR: 8357393: RichTextArea: fails to properly save text attributes
 [v2]
In-Reply-To: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com>
References: <2IRCfnsdO_UfFuYPXkMoMuoATL47Ko1gWqemyeanI60=.c7b72134-e582-4bfb-aaab-5412ea554c4b@github.com>
Message-ID: <Cv0n7SiQRiO6YZeWi05nuM-s93X1qYove-aQ-Mkl3nk=.9e18d469-d527-49a9-84b0-419a5594938b@github.com>

> Fixing a bug that breaks proper serialization of character attributes.
> 
> This, unfortunately, makes a breaking change in the RichTextArea native format [0].
> 
> ## References
> 
> [0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea_DataFormat_V2.md

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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8357393.attr.ser
 - test
 - tests
 - fixed attribute serialization

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1813/files
  - new: https://git.openjdk.org/jfx/pull/1813/files/06b31815..147502bf

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

  Stats: 572 lines in 26 files changed: 522 ins; 12 del; 38 mod
  Patch: https://git.openjdk.org/jfx/pull/1813.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1813/head:pull/1813

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

From angorya at openjdk.org  Thu May 29 18:45:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 May 2025 18:45:42 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v3]
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <vsORsKCXwagTuuFwtwG3lFS_kE1HKNj28tKTgt-ZMmY=.33c0b8ad-86e4-4e4e-8f54-42af9bbdc2d1@github.com>

> Tries to address the mystery of missing graphic in the TabPane overflow menu.
> 
> ### Summary of Changes
> 
> - minor `TabPaneSkin` constructor javadoc clarification
> - added the property
> - changed popup menu to be created on demand
> - removing adding the popup reference to the `TabHeaderSkin` properties (I think it was done for testing purposes, I could not find any references to it in the code)
>  
> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java
> 
> # Overflow Menu Graphic Property in the TabPaneSkin
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
> 
> 
> 
> ## Goals
> 
> The goals of this proposal are:
> 
> - to allow the application developers to customize the overflow menu items' graphic
> - retain the backward compatibility with the existing application code
> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - disable the overflow menu
> - configure overflow menu graphic property via CSS
> - add this property to the `TabPane` control itself
> 
> 
> 
> ## Motivation
> 
> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
> an `ImageView` or `Label` with an `ImageView`.
> 
> This limitation makes it impossible for the application developer to use other graphic Nodes,
> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
> when the tabs in the `TabPane` have no text.
> 
> Example:
> 
> 
> public class TabPaneGraphicFactoryExample {
>     public void example() {
>         Tab tab1 = new Tab("Tab1");
>         tab1.setGraphic(createGraphic(tab1));
> 
>         Tab tab2 = new Tab("Tab2");
>         tab2.setGraphic(createGraphic(tab2));
> 
>         TabPane tabPane = new TabPane();
>         tabPane.getTabs().addAll(tab1, tab2);
> 
>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>         // set overflow menu factory with the same method as was used to create the tabs
>         skin.setMenuGraphicFactory(this::createGraphic);
>         tabPane.setSkin(skin);
>     }
> 
>     // creates graphic Nodes for tabs as well as the overflow menu
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2"...

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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - popup menu on demand
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - graphic factory

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/7cb4fa8e..7a1a0289

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

  Stats: 119635 lines in 270 files changed: 28082 ins; 51344 del; 40209 mod
  Patch: https://git.openjdk.org/jfx/pull/1773.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1773/head:pull/1773

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

From dlemmermann at gmail.com  Thu May 29 18:52:08 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Thu, 29 May 2025 20:52:08 +0200
Subject: CSS roadmap proposal
In-Reply-To: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>
References: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>
Message-ID: <D3D31F0A-6A94-404B-8F77-B2577CD7CCB7@gmail.com>

No bikeshedding attempt here, just some high level feedback regarding 4 / 5 ?new theme": I have recently migrated our entire CRM application to AtlantaFX [1] which is based on GitHub Primer. Primer is not just a theme, it is a complete design system [3]. I think that any new design should be based on such a design system, as it defines semantics, e.g. ?semantic colors?. By doing this it becomes very easy to customize a theme. We now get dark themes ?for free?. A design system also gives you instructions on how you should design certain aspects of your application. As this might go too far for an out of the box theme I think there are still some valuable lessons to be learned from this approach. I can definitely say that the overall styling of our application has become much more consistent than before and much more simple. Using AtlantaFX has brought me closer to the world of design systems and has taught me many valuable lessons. I would strongly suggest to study its concepts / ideas before diving into a new theme.

[1] https://github.com/mkpaz/atlantafx
[2] https://primer.style/
[3] https://en.wikipedia.org/wiki/Design_system#:~:text=A%20design%20system%20is%20a,consistency%20and%20efficiency%20across%20projects.



> Am 29.05.2025 um 20:31 schrieb Michael Strau? <michaelstrau2 at gmail.com>:
> 
> Here is how I think we should be evolving JavaFX CSS over the next
> period of time:
> 
> 1. Media queries
> Gist: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7
> PR: https://github.com/openjdk/jfx/pull/1655
> 
> This feature is already out for review.
> 
> 2. System colors
> Gist: https://gist.github.com/mstr2/afac42ab9587c1040a6cf7b091cee99f
> 
> System colors allow stylesheet authors to use colors that are defined
> by the scene or the platform. Most notably, this includes the accent
> color. We will also add new media queries to help stylesheet authors
> deal with contrast modes.
> 
> 3. With media queries and system colors in place, we can remove the
> built-in high contrast stylesheets that come with Caspian and Modena.
> Instead of hard-coding these special cases (and not even in a good
> way), we can now use standard APIs to achieve a better result. This
> will remove a big chunk of special-casing from the codebase and bring
> us closer to an equal playing field of built-in vs. third-party
> themes.
> 
> 4. Dark Modena / Modena 2025?
> 
> 5. Bold new theme?
> 
> 
> What do you think? Please focus comments on step 1-3, and not on
> bikeshedding a new theme.

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

From thiago.sayao at gmail.com  Thu May 29 19:23:08 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 29 May 2025 16:23:08 -0300
Subject: CSS roadmap proposal
In-Reply-To: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>
References: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>
Message-ID: <CAAP_wukzgPLENXfzUMFBZ7VNZUjnpBC=nxCOFiKR8XZiJOAsbw@mail.gmail.com>

Hi,

- Allow global CSS. I might be missing something, but I think there's no
easy way to tell JavaFx
to use a CSS for the entire application.

- Font Family Fallback: Add support for font family fallbacks in
-fx-font-family, similar to standard CSS.
 For example: -fx-font-family: "Inter", "Noto Sans", sans-serif;

- Media Queries for device/screen size: Introduce support for media queries
to adapt styles based on screen size,
resolution, or other device characteristics. This will help usage of JavaFx
outside of "desktop applications" scope,
especially on devices where the application takes the entire screen.

- Image Scaling: Provide a declarative way to scale images relative to
their container size (e.g., percentage-based width/height).

I?d be cautious about introducing an entirely new theme, as it could
significantly increase the long-term maintenance effort.
I would instead, improve modena by allowing it to be more customizable.

-- Thiago.



Em qui., 29 de mai. de 2025 ?s 15:32, Michael Strau? <
michaelstrau2 at gmail.com> escreveu:

> Here is how I think we should be evolving JavaFX CSS over the next
> period of time:
>
> 1. Media queries
> Gist: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7
> PR: https://github.com/openjdk/jfx/pull/1655
>
> This feature is already out for review.
>
> 2. System colors
> Gist: https://gist.github.com/mstr2/afac42ab9587c1040a6cf7b091cee99f
>
> System colors allow stylesheet authors to use colors that are defined
> by the scene or the platform. Most notably, this includes the accent
> color. We will also add new media queries to help stylesheet authors
> deal with contrast modes.
>
> 3. With media queries and system colors in place, we can remove the
> built-in high contrast stylesheets that come with Caspian and Modena.
> Instead of hard-coding these special cases (and not even in a good
> way), we can now use standard APIs to achieve a better result. This
> will remove a big chunk of special-casing from the codebase and bring
> us closer to an equal playing field of built-in vs. third-party
> themes.
>
> 4. Dark Modena / Modena 2025?
>
> 5. Bold new theme?
>
>
> What do you think? Please focus comments on step 1-3, and not on
> bikeshedding a new theme.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250529/18cd8bfc/attachment.htm>

From tsayao at openjdk.org  Thu May 29 20:26:40 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 29 May 2025 20:26:40 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v25]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <zndzrAsrLrHp5-NMwoMULTXs_GX6yeOCD8Fqv7JMN0A=.c87cc25d-85b3-4f7f-b059-f1b44a2b4fd5@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Improve StageOwnershipTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/36c57e15..c0c417a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=24
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=23-24

  Stats: 311 lines in 1 file changed: 29 ins; 242 del; 40 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From mfox at openjdk.org  Thu May 29 20:41:02 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 29 May 2025 20:41:02 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v24]
In-Reply-To: <MQc9NVvdhVGfSQxeWXrR6yBmPizt24lLsGRbGA6djk4=.7bec7901-2c6f-4cb0-90e2-78c175d7db1f@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <eCNbi27fhaQEj3aClLfSnk66IKOEPZRTYT1MdMPzYRU=.28322f86-c197-4d5c-80eb-ad4eb50cc541@github.com>
 <MQc9NVvdhVGfSQxeWXrR6yBmPizt24lLsGRbGA6djk4=.7bec7901-2c6f-4cb0-90e2-78c175d7db1f@github.com>
Message-ID: <RCTJCED52EpTX7l1R7UNwXMrNGxkQ8dBNDnhSt8PTg8=.7fb22eb9-5868-4ad2-b4b3-35b762553247@github.com>

On Thu, 29 May 2025 18:12:25 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> I now own a mac mini m4 so I can test on mac. Still scared of building on windows :)

I'm putting together some PR's to deal with the Mac bugs. Any test related to maximization is probably going to fail due to [JDK-8355990](https://bugs.openjdk.org/browse/JDK-8355990). I also have a PR for the bug where the OS respects the min and max window sizes but doesn't send the proper notifications to update the properties on the JFX window.

I'll handle running these tests on Windows.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2920527839

From tsayao at openjdk.org  Thu May 29 20:57:37 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 29 May 2025 20:57:37 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v26]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <DUACIU6C6uD4U6vj9gjvz5_8VX_04ukiFfXOwD8Mc0E=.7d716e1b-1f3c-402e-8eaa-5cbaec22050d@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. Use GDK for creating Windows. Since we paint directly to the underlying XWindow, creating a GtkWidget for the window is unnecessary and results in unused GTK resources. Additionally, avoiding the use of a GtkWidget eliminates the need for workarounds caused by conflicting GTK behavior?such as setting the initial window state, position, or size.
> 2. It aligns with X11's asynchronous behavior by reporting geometry changes only upon receiving a configure event, since requests to the window manager aren't guaranteed to be honored. However, changes are still reported immediately in special cases, such as before the window is mapped. For example, a request to move the window to (0, 0) might be overridden by the window manager, placing it in the top-right corner below the panels instead.
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not mapped);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
> 
> A simple manual test is provided:
> `java @build/run.args tests/manual/stage/TestStage.java `
> 
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window pos...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/c0c417a4..33e32967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=25
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=24-25

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

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

From thiago.sayao at gmail.com  Thu May 29 21:29:56 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 29 May 2025 18:29:56 -0300
Subject: CSS roadmap proposal
In-Reply-To: <CAAP_wukzgPLENXfzUMFBZ7VNZUjnpBC=nxCOFiKR8XZiJOAsbw@mail.gmail.com>
References: <CAJEpuXRjZKHyVyX4bSfP_GK6BTpgnXe-Eg9TVuCjLrHH7JoQtQ@mail.gmail.com>
 <CAAP_wukzgPLENXfzUMFBZ7VNZUjnpBC=nxCOFiKR8XZiJOAsbw@mail.gmail.com>
Message-ID: <CAAP_wumRwaOQ+cmoQi+cWb1KFM4RvQA8aF3cYY_KBKfK5Rv-2Q@mail.gmail.com>

>
> - Allow global CSS. I might be missing something, but I think there's no
> easy way to tell JavaFx
> to use a CSS for the entire application.


There is Application.setUserAgentStylesheet, but I meant adding CSS files
on top of modena, not replacing it.


Em qui., 29 de mai. de 2025 ?s 16:23, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> Hi,
>
> - Allow global CSS. I might be missing something, but I think there's no
> easy way to tell JavaFx
> to use a CSS for the entire application.
>
> - Font Family Fallback: Add support for font family fallbacks in
> -fx-font-family, similar to standard CSS.
>  For example: -fx-font-family: "Inter", "Noto Sans", sans-serif;
>
> - Media Queries for device/screen size: Introduce support for media
> queries to adapt styles based on screen size,
> resolution, or other device characteristics. This will help usage of
> JavaFx outside of "desktop applications" scope,
> especially on devices where the application takes the entire screen.
>
> - Image Scaling: Provide a declarative way to scale images relative to
> their container size (e.g., percentage-based width/height).
>
> I?d be cautious about introducing an entirely new theme, as it could
> significantly increase the long-term maintenance effort.
> I would instead, improve modena by allowing it to be more customizable.
>
> -- Thiago.
>
>
>
> Em qui., 29 de mai. de 2025 ?s 15:32, Michael Strau? <
> michaelstrau2 at gmail.com> escreveu:
>
>> Here is how I think we should be evolving JavaFX CSS over the next
>> period of time:
>>
>> 1. Media queries
>> Gist: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7
>> PR: https://github.com/openjdk/jfx/pull/1655
>>
>> This feature is already out for review.
>>
>> 2. System colors
>> Gist: https://gist.github.com/mstr2/afac42ab9587c1040a6cf7b091cee99f
>>
>> System colors allow stylesheet authors to use colors that are defined
>> by the scene or the platform. Most notably, this includes the accent
>> color. We will also add new media queries to help stylesheet authors
>> deal with contrast modes.
>>
>> 3. With media queries and system colors in place, we can remove the
>> built-in high contrast stylesheets that come with Caspian and Modena.
>> Instead of hard-coding these special cases (and not even in a good
>> way), we can now use standard APIs to achieve a better result. This
>> will remove a big chunk of special-casing from the codebase and bring
>> us closer to an equal playing field of built-in vs. third-party
>> themes.
>>
>> 4. Dark Modena / Modena 2025?
>>
>> 5. Bold new theme?
>>
>>
>> What do you think? Please focus comments on step 1-3, and not on
>> bikeshedding a new theme.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250529/55c10736/attachment.htm>

From philip.race at oracle.com  Thu May 29 22:43:39 2025
From: philip.race at oracle.com (Philip Race)
Date: Thu, 29 May 2025 15:43:39 -0700
Subject: Font Weights
In-Reply-To: <EE896AC8-C343-40F7-8B3C-78288214E3B6@gmail.com>
References: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>
 <af4bd032-359d-43ef-8df5-81a878bb589c@gmail.com>
 <EE896AC8-C343-40F7-8B3C-78288214E3B6@gmail.com>
Message-ID: <3ca8739e-8af5-4d51-9652-2e81eb1524a2@oracle.com>

There's probably a bug on this but I think the font look up code may 
need some work

I think the CSS code may be using family + weight but then it reaches
com/sun/javafx/font/PrismFontLoader.java

 ?? // REMIND. Some day need to have better granularity.

 ??????? boolean bold = weight != null &&
 ?????????????????????? weight.ordinal() >= FontWeight.BOLD.ordinal();

And we don't have an API to return the FontWeight so you can't figure it 
out for yourself.
I really should fix all of the above.

Is the CSS code part all good though ?

Looking at CssParser I'm not sure what its doing is the intention of 
bolder and lighter
 ??????? } else if ("bolder".equals(ident)) {
 ??????????? weight = FontWeight.BOLD.name();
 ??????? } else if ("lighter".equals(ident)) {
 ??????????? weight = FontWeight.LIGHT.name();

I assume they are meant to say find something *relative*, not *absolute*
Perhaps in the absence of the API to find the real weight it wasn't 
implementable ?

-phil

On 5/29/25 11:33 AM, Dirk Lemmermann wrote:
> I think what I really want is that this feature ?simply? works as 
> documented. I have not looked at the implementation of the font 
> support, yet, but it feels like this shouldn?t be too hard to 
> implement correctly. If somebody knows more about the problem I would 
> love to hear about it.
>
> The official JavaFX CSS reference documentation at 
> https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/doc-files/cssref.html?lists 
> font weights (integers) as possible values:
>
> <font-weight>?The font's weight, using the following syntax:
> [ normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 
> | 700 | 800 | 900 ]
>
> ?If this will never be supported then I think the docs need to reflect 
> that.
>
> Again, the main benefit of this working properly would be that 
> applications wouldn?t have to use the workaround anymore where the 
> font family name will be used directly in all the places where a piece 
> of text has a different weight than the default one.
>
> Dirk
>
>> Am 29.05.2025 um 20:03 schrieb John Hendrikx <john.hendrikx at gmail.com>:
>>
>>
>> On 29/05/2025 18:23, Dirk Lemmermann wrote:
>>> Hi everyone,
>>>
>>> Is there any chance we can get font weight working properly so that I can use a font with medium boldness and use it by declaring: -fx-font-weight: bolder; or by declaring -fx-font-weight: 600;? I know I can work around it by using the font family name, e.g. ?Rubik Medium? but this makes it impossible to replace the font at runtime, which is a requirement I am facing right now in order to support users with dyslexia. I was also considering using a variable but this is not supported for font family names (e,g, ?-my-font; ?Rubik Medium?).
>> Just curious, how would a variable help here for the problem having 
>> the font selectable at runtime?
>>> Any other work arounds I am missing?
>>
>> I don't have any easy solutions here, and I'm unsure what is involved 
>> in actually making -fx-font-weight work better.
>>
>> So,?all I can offer is something very ugly like having the user 
>> select a font, then generating a CSS file, and setting that on the 
>> root node; if you keep the styles for font selection separate it may 
>> be doable as you'd probably could get away with just replacing a 
>> single stylesheet then (ie. mark a TextField with ".font-large" 
>> specifically and define what that means in the custom CSS file).? 
>> This is a bit anti-CSS as you'd prefer to mark such nodes only with 
>> their intended function, and determine a suitable font based on that, 
>> but styles in FX don't compose.
>>
>> If you're willing to go in the direction of generating all CSS files 
>> based on LESS or SCSS (at runtime mind you, I hate doing this during 
>> a build), more is possible:
>>
>> What I've been doing myself (although I don't allow runtime 
>> selection) is to allow users to modify CSS files; using?LESS or SCSS 
>> one can neatly pack all font related stuff into a single file, so 
>> I've sort of solved this by having a `fonts.less` (see below).? I 
>> then mark styles with one of the custom styles (.light, .regular, 
>> etc) to indicate what final font they'll be using. However, to make 
>> this work even at run time, I'd have to regenerate all derived CSS 
>> files (but as I said, I can do this at runtime anyway) -- so the 
>> effort is in then primarily in auto-generating a base fonts CSS file 
>> given some user selection, then replacing all stylesheets that were 
>> set throughout the application (or just?restarting the application).
>>
>> For now a user could?do this manually by only editing `fonts.less` 
>> and then (re)starting the application.
>>
>> Here is the fonts.less file I was talking about (note: there is also 
>> a Linux variant as fonts work differently on different platforms as 
>> well... perhaps MacOS needs a modified one also, but I never tried there)
>>
>> fonts.less:
>>
>> /*
>> * The Noto Sans font supports many variations. To get the correct 
>> variation
>> * in JavaFX, select them as follows:
>> *
>> * - Black = Noto Sans Blk
>> * - Bold = Noto Sans + font-weight: bold
>> * - Semi Bold = Noto Sans SemBd
>> * - Medium = Noto Sans Med
>> * - Regular = Noto Sans + font-weight: normal
>> * - Light = Noto Sans Light
>> *
>> * Note that these names are for Windows. Other platforms can use
>> * slightly different names.
>> */
>>
>> .light {
>> -fx-font-family: "Noto Sans Light";
>> -fx-font-weight: normal;
>> }
>>
>> .regular {
>> -fx-font-family: "Noto Sans";
>> -fx-font-weight: normal;
>> }
>>
>> .medium {
>> -fx-font-family: "Noto Sans Med";
>> -fx-font-weight: bold;
>> }
>>
>> .semi-bold {
>> -fx-font-family: "Noto Sans SemBd";
>> -fx-font-weight: bold;
>> }
>>
>> .bold {
>> -fx-font-family: "Noto Sans";
>> -fx-font-weight: bold;
>> }
>>
>> .black {
>> -fx-font-family: "Noto Sans Blk";
>> -fx-font-weight: bold;
>> }
>>
>> fonts-linux.less:
>>
>> .light { -fx-font-family: "Noto Sans Light"; -fx-font-weight: normal; 
>> } .regular { -fx-font-family: "Noto Sans"; -fx-font-weight: normal; } 
>> .medium { -fx-font-family: "Noto Sans Medium"; -fx-font-weight: 
>> normal; } .semi-bold { -fx-font-family: "Noto Sans SemiBold"; 
>> -fx-font-weight: normal; } .bold { -fx-font-family: "Noto Sans"; 
>> -fx-font-weight: bold; } .black { -fx-font-family: "Noto Sans Black"; 
>> -fx-font-weight: normal; } And using it for some arbitrary style is 
>> then done (also with LESS) like:
>>
>> .style-p3-extra-light {
>> -fx-font-size: 15;
>> .light;
>> }
>>
>> Not what you hoped for I think :)
>>
>> --John
>>
>>> Dirk
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250529/b98f9d70/attachment-0001.htm>

From philip.race at oracle.com  Thu May 29 23:09:45 2025
From: philip.race at oracle.com (Philip Race)
Date: Thu, 29 May 2025 16:09:45 -0700
Subject: Font Weights
In-Reply-To: <3ca8739e-8af5-4d51-9652-2e81eb1524a2@oracle.com>
References: <41D3226C-3A6A-4C5A-B9DA-0F1565DA06E1@gmail.com>
 <af4bd032-359d-43ef-8df5-81a878bb589c@gmail.com>
 <EE896AC8-C343-40F7-8B3C-78288214E3B6@gmail.com>
 <3ca8739e-8af5-4d51-9652-2e81eb1524a2@oracle.com>
Message-ID: <e834231e-b7c3-4853-9ffa-7466ec922064@oracle.com>

https://bugs.openjdk.org/browse/JDK-8090423

but part of it is that we aren't doing extended families - clearer with 
this one

https://bugs.openjdk.org/browse/JDK-8344037

So a chunk of work.

And here's the bug to report the weights
https://bugs.openjdk.org/browse/JDK-8092191

-phil.

On 5/29/25 3:43 PM, Philip Race wrote:
> There's probably a bug on this but I think the font look up code may 
> need some work
>
> I think the CSS code may be using family + weight but then it reaches
> com/sun/javafx/font/PrismFontLoader.java
>
> ?? // REMIND. Some day need to have better granularity.
>
> ??????? boolean bold = weight != null &&
> ?????????????????????? weight.ordinal() >= FontWeight.BOLD.ordinal();
>
> And we don't have an API to return the FontWeight so you can't figure 
> it out for yourself.
> I really should fix all of the above.
>
> Is the CSS code part all good though ?
>
> Looking at CssParser I'm not sure what its doing is the intention of 
> bolder and lighter
> ??????? } else if ("bolder".equals(ident)) {
> ??????????? weight = FontWeight.BOLD.name();
> ??????? } else if ("lighter".equals(ident)) {
> ??????????? weight = FontWeight.LIGHT.name();
>
> I assume they are meant to say find something *relative*, not *absolute*
> Perhaps in the absence of the API to find the real weight it wasn't 
> implementable ?
>
> -phil
>
> On 5/29/25 11:33 AM, Dirk Lemmermann wrote:
>> I think what I really want is that this feature ?simply? works as 
>> documented. I have not looked at the implementation of the font 
>> support, yet, but it feels like this shouldn?t be too hard to 
>> implement correctly. If somebody knows more about the problem I would 
>> love to hear about it.
>>
>> The official JavaFX CSS reference documentation at 
>> https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/doc-files/cssref.html?lists 
>> font weights (integers) as possible values:
>>
>> <font-weight>?The font's weight, using the following syntax:
>> [ normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 
>> 600 | 700 | 800 | 900 ]
>>
>> ?If this will never be supported then I think the docs need to 
>> reflect that.
>>
>> Again, the main benefit of this working properly would be that 
>> applications wouldn?t have to use the workaround anymore where the 
>> font family name will be used directly in all the places where a 
>> piece of text has a different weight than the default one.
>>
>> Dirk
>>
>>> Am 29.05.2025 um 20:03 schrieb John Hendrikx <john.hendrikx at gmail.com>:
>>>
>>>
>>> On 29/05/2025 18:23, Dirk Lemmermann wrote:
>>>> Hi everyone,
>>>>
>>>> Is there any chance we can get font weight working properly so that I can use a font with medium boldness and use it by declaring: -fx-font-weight: bolder; or by declaring -fx-font-weight: 600;? I know I can work around it by using the font family name, e.g. ?Rubik Medium? but this makes it impossible to replace the font at runtime, which is a requirement I am facing right now in order to support users with dyslexia. I was also considering using a variable but this is not supported for font family names (e,g, ?-my-font; ?Rubik Medium?).
>>> Just curious, how would a variable help here for the problem having 
>>> the font selectable at runtime?
>>>> Any other work arounds I am missing?
>>>
>>> I don't have any easy solutions here, and I'm unsure what is 
>>> involved in actually making -fx-font-weight work better.
>>>
>>> So,?all I can offer is something very ugly like having the user 
>>> select a font, then generating a CSS file, and setting that on the 
>>> root node; if you keep the styles for font selection separate it may 
>>> be doable as you'd probably could get away with just replacing a 
>>> single stylesheet then (ie. mark a TextField with ".font-large" 
>>> specifically and define what that means in the custom CSS file).? 
>>> This is a bit anti-CSS as you'd prefer to mark such nodes only with 
>>> their intended function, and determine a suitable font based on 
>>> that, but styles in FX don't compose.
>>>
>>> If you're willing to go in the direction of generating all CSS files 
>>> based on LESS or SCSS (at runtime mind you, I hate doing this during 
>>> a build), more is possible:
>>>
>>> What I've been doing myself (although I don't allow runtime 
>>> selection) is to allow users to modify CSS files; using?LESS or SCSS 
>>> one can neatly pack all font related stuff into a single file, so 
>>> I've sort of solved this by having a `fonts.less` (see below).? I 
>>> then mark styles with one of the custom styles (.light, .regular, 
>>> etc) to indicate what final font they'll be using.? However, to make 
>>> this work even at run time, I'd have to regenerate all derived CSS 
>>> files (but as I said, I can do this at runtime anyway) -- so the 
>>> effort is in then primarily in auto-generating a base fonts CSS file 
>>> given some user selection, then replacing all stylesheets that were 
>>> set throughout the application (or just?restarting the application).
>>>
>>> For now a user could?do this manually by only editing `fonts.less` 
>>> and then (re)starting the application.
>>>
>>> Here is the fonts.less file I was talking about (note: there is also 
>>> a Linux variant as fonts work differently on different platforms as 
>>> well... perhaps MacOS needs a modified one also, but I never tried 
>>> there)
>>>
>>> fonts.less:
>>>
>>> /*
>>> * The Noto Sans font supports many variations. To get the correct 
>>> variation
>>> * in JavaFX, select them as follows:
>>> *
>>> * - Black = Noto Sans Blk
>>> * - Bold = Noto Sans + font-weight: bold
>>> * - Semi Bold = Noto Sans SemBd
>>> * - Medium = Noto Sans Med
>>> * - Regular = Noto Sans + font-weight: normal
>>> * - Light = Noto Sans Light
>>> *
>>> * Note that these names are for Windows. Other platforms can use
>>> * slightly different names.
>>> */
>>>
>>> .light {
>>> -fx-font-family: "Noto Sans Light";
>>> -fx-font-weight: normal;
>>> }
>>>
>>> .regular {
>>> -fx-font-family: "Noto Sans";
>>> -fx-font-weight: normal;
>>> }
>>>
>>> .medium {
>>> -fx-font-family: "Noto Sans Med";
>>> -fx-font-weight: bold;
>>> }
>>>
>>> .semi-bold {
>>> -fx-font-family: "Noto Sans SemBd";
>>> -fx-font-weight: bold;
>>> }
>>>
>>> .bold {
>>> -fx-font-family: "Noto Sans";
>>> -fx-font-weight: bold;
>>> }
>>>
>>> .black {
>>> -fx-font-family: "Noto Sans Blk";
>>> -fx-font-weight: bold;
>>> }
>>>
>>> fonts-linux.less:
>>>
>>> .light { -fx-font-family: "Noto Sans Light"; -fx-font-weight: 
>>> normal; } .regular { -fx-font-family: "Noto Sans"; -fx-font-weight: 
>>> normal; } .medium { -fx-font-family: "Noto Sans Medium"; 
>>> -fx-font-weight: normal; } .semi-bold { -fx-font-family: "Noto Sans 
>>> SemiBold"; -fx-font-weight: normal; } .bold { -fx-font-family: "Noto 
>>> Sans"; -fx-font-weight: bold; } .black { -fx-font-family: "Noto Sans 
>>> Black"; -fx-font-weight: normal; } And using it for some arbitrary 
>>> style is then done (also with LESS) like:
>>>
>>> .style-p3-extra-light {
>>> -fx-font-size: 15;
>>> .light;
>>> }
>>>
>>> Not what you hoped for I think :)
>>>
>>> --John
>>>
>>>> Dirk
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250529/1728d270/attachment-0001.htm>

From lukasz.kostyra at oracle.com  Fri May 30 06:32:17 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 30 May 2025 06:32:17 +0000
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <DM3PPF3367D7B9BF3F43D1705D9963E286DFE61A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Vote: YES

- Lukasz

-----Original Message-----
From: openjfx-dev <openjfx-dev-retn at openjdk.org> On Behalf Of Kevin Rushforth
Sent: Wednesday, 28 May 2025 21:51
To: openjfx-dev <openjfx-dev at openjdk.org>; Alexander Zuev <alexander.zuev at oracle.com>
Subject: CFV: New OpenJFX Committer: Alexander Zuev

I hereby nominate Alexander Zuev [1] to OpenJFX Committer.

Alexander is a member of the JavaFX team at Oracle who has contributed
10 commits [2] to OpenJFX.

Votes are due by June 11, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#kizune

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer


From lukasz.kostyra at oracle.com  Fri May 30 06:49:41 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 30 May 2025 06:49:41 +0000
Subject: JavaFX Direct3D 12 first EA release
Message-ID: <DM3PPF3367D7B9B828287870399FEB13CE5FE61A@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Hello openjfx-dev,

The first Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/

Please test this bundle and share your feedback by:
- emailing openjfx-dev at openjdk.java.net or
- reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com

This is the first EA release and some work is still in progress, so you may encounter issues.

Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates.

Important Notes:
1. This is a Windows-specific feature, so only a Windows-specific bundle is provided.
2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing.
3. It is recommended to use JDK 24 or later.
4. At this stage D3D12 backend is feature-complete, however optimization and performance have not been the focus yet. There?s still a number of improvements and adjustments that must be made in order to match/surpass D3D backend. Notable areas known to us which need improvements are the 3D pipeline and cases where color blending is used - they will work but they will be (much) slower than D3D. Please keep that in mind when testing.
5. Issue behavior may vary across different hardware. So, please provide detailed information, such as the output of "java -Dprism.verbose=true", when reporting or discussing issues.
6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx]

We look forward to your feedback.

Regards,
Lukasz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250530/4b6de1ec/attachment-0001.htm>

From jayathirth.d.v at oracle.com  Fri May 30 07:10:18 2025
From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy)
Date: Fri, 30 May 2025 07:10:18 +0000
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <PH7PR10MB6649D41900A40ED8EE67F92FB961A@PH7PR10MB6649.namprd10.prod.outlook.com>

Vote : Yes

Thanks,
Jay

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Thursday, 29 May 2025 at 1:21?AM
To: openjfx-dev <openjfx-dev at openjdk.org>, Alexander Zuev <alexander.zuev at oracle.com>
Subject: CFV: New OpenJFX Committer: Alexander Zuev
I hereby nominate Alexander Zuev [1] to OpenJFX Committer.

Alexander is a member of the JavaFX team at Oracle who has contributed
10 commits [2] to OpenJFX.

Votes are due by June 11, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#kizune

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250530/bb258859/attachment.htm>

From jose.pereda at gluonhq.com  Fri May 30 07:45:51 2025
From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=)
Date: Fri, 30 May 2025 09:45:51 +0200
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <PH7PR10MB6649D41900A40ED8EE67F92FB961A@PH7PR10MB6649.namprd10.prod.outlook.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
 <PH7PR10MB6649D41900A40ED8EE67F92FB961A@PH7PR10MB6649.namprd10.prod.outlook.com>
Message-ID: <CAGMSBrJQ1fRZy4JV7DnQ6SKN3KjNJHtqCZdGO6MbRHMA=_GmSQ@mail.gmail.com>

Vote: Yes

Jose

On Fri, May 30, 2025 at 9:11?AM Jayathirth Rao Daarapuram Venkatesh Murthy <
jayathirth.d.v at oracle.com> wrote:

> Vote : Yes
>
>
>
> Thanks,
>
> Jay
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Thursday, 29 May 2025 at 1:21?AM
> *To: *openjfx-dev <openjfx-dev at openjdk.org>, Alexander Zuev <
> alexander.zuev at oracle.com>
> *Subject: *CFV: New OpenJFX Committer: Alexander Zuev
>
> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.
>
> Alexander is a member of the JavaFX team at Oracle who has contributed
> 10 commits [2] to OpenJFX.
>
> Votes are due by June 11, 2025 at 20:00 UTC.
>
> Only current OpenJFX Committers [3] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [4]. Nomination to a project
> Committer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#kizune
>
> [2]
>
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits
>
> [3] https://openjdk.org/census#openjfx
>
> [4] https://openjdk.org/bylaws#lazy-consensus
>
> [5] https://openjdk.org/projects#project-committer
>


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

From nlisker at gmail.com  Fri May 30 08:37:01 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 30 May 2025 10:37:01 +0200
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <CAGMSBrJQ1fRZy4JV7DnQ6SKN3KjNJHtqCZdGO6MbRHMA=_GmSQ@mail.gmail.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
 <PH7PR10MB6649D41900A40ED8EE67F92FB961A@PH7PR10MB6649.namprd10.prod.outlook.com>
 <CAGMSBrJQ1fRZy4JV7DnQ6SKN3KjNJHtqCZdGO6MbRHMA=_GmSQ@mail.gmail.com>
Message-ID: <CA+0ynh8iCA0nuLUQMOZf0hjE5jKfocKN_76QrNtHigFgonCADg@mail.gmail.com>

Vote: YES

On Fri, May 30, 2025, 09:46 Jos? Pereda <jose.pereda at gluonhq.com> wrote:

> Vote: Yes
>
> Jose
>
> On Fri, May 30, 2025 at 9:11?AM Jayathirth Rao Daarapuram Venkatesh Murthy
> <jayathirth.d.v at oracle.com> wrote:
>
>> Vote : Yes
>>
>>
>>
>> Thanks,
>>
>> Jay
>>
>>
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
>> Rushforth <kevin.rushforth at oracle.com>
>> *Date: *Thursday, 29 May 2025 at 1:21?AM
>> *To: *openjfx-dev <openjfx-dev at openjdk.org>, Alexander Zuev <
>> alexander.zuev at oracle.com>
>> *Subject: *CFV: New OpenJFX Committer: Alexander Zuev
>>
>> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.
>>
>> Alexander is a member of the JavaFX team at Oracle who has contributed
>> 10 commits [2] to OpenJFX.
>>
>> Votes are due by June 11, 2025 at 20:00 UTC.
>>
>> Only current OpenJFX Committers [3] are eligible to vote on this
>> nomination. Votes must be cast in the open by replying to this mailing
>> list.
>>
>> For Lazy Consensus voting instructions, see [4]. Nomination to a project
>> Committer is described in [5].
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>> [1] https://openjdk.org/census#kizune
>>
>> [2]
>>
>> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Alexander%20Zuev%22&type=commits
>>
>> [3] https://openjdk.org/census#openjfx
>>
>> [4] https://openjdk.org/bylaws#lazy-consensus
>>
>> [5] https://openjdk.org/projects#project-committer
>>
>
>
> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250530/2d51e527/attachment.htm>

From john at status6.com  Fri May 30 14:26:00 2025
From: john at status6.com (John Neffenger)
Date: Fri, 30 May 2025 07:26:00 -0700
Subject: CFV: New OpenJFX Committer: Alexander Zuev
In-Reply-To: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
References: <a6228f17-f678-4bd9-aa9c-d3604bd1f365@oracle.com>
Message-ID: <2ee4015e-62e6-4fb5-b78c-83d662f2bc7f@status6.com>

Vote: YES

John

On 5/28/25 12:51 PM, Kevin Rushforth wrote:
> I hereby nominate Alexander Zuev [1] to OpenJFX Committer.