From lbourges at openjdk.org  Fri Nov  1 07:25:37 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 1 Nov 2024 07:25:37 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
Message-ID: <omWYsQAdx5IRCXJ88epgluXn11jjLSEFxr65hh2AsbY=.7c887364-3275-46d6-8d32-5cff5a242bfb@github.com>

On Thu, 31 Oct 2024 14:09:52 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR removes uses of `AccessControler.doPrivileged()` from `javafx.graphics` package. All uses of `doPrivileged()` were removed _excluding_ `com.sun.javafx.tk` and `com.sun.ui.glass` subpackages - those are handled by [JDK-8342453](https://bugs.openjdk.org/browse/JDK-8342453) (already completed) and [JDK-8342454](https://bugs.openjdk.org/browse/JDK-8342454) respectively.
>> 
>> Most of these changes are fairly straightforward and follow the standard replacement from `AccessController.doPrivileged(LAMBDA)` to just simply `LAMBDA` with a couple exceptions:
>> 
>> - `StyleManager.java` where `loadStylesheet()` followed two steps - attempting straightforward stylesheet load via `loadStylesheetUnPrivileged()` and in case of `AccessControlException` retrying the load via `AccessController.doPrivileged` with read-only access to stylesheet JAR. Now that `doPrivileged` is deprecated and not used anymore, `loadStylesheetUnPrivileged()` was always successful and the fallback became essentially dead code. Fallback was removed and `loadStylesheetUnPrivileged()` was renamed to `loadStylesheet()`.
>> - `Scene.java` integrates with `com.sun.javafx.tk` so only straightforward `doPrivileged()` calls were removed - `AccessControlContext` remained, as it needs to be removed from both tk and Scene via a follow-up ([JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993))
>> 
>> Building graphics module now produces less warnings than before this change with no new warning messages (all warnings refer to the use of `Unsafe` which is out of scope of this change).
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Scene: Remove missed doPrivileged use

Changes to marlin classes look good to me!

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

PR Comment: https://git.openjdk.org/jfx/pull/1619#issuecomment-2451424446

From lbourges at openjdk.org  Fri Nov  1 07:25:38 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 1 Nov 2024 07:25:38 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <ZjPm5iu5DE4jnm71Au9pBJUjFviH-_Sdw6htlaEcQC8=.e2f64756-3331-464e-9b18-89936facf0d4@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <Y7UDFbID4AtX5y8PIgewOs0HmFZWOke-jMfm49fk1fg=.5231c164-5d01-4e76-afeb-5da3690788b9@github.com>
 <ZjPm5iu5DE4jnm71Au9pBJUjFviH-_Sdw6htlaEcQC8=.e2f64756-3331-464e-9b18-89936facf0d4@github.com>
Message-ID: <DTLx-PaZrwi-Hr518Wf2hNs59ffv2K5JkP3YOzw5zTg=.227ae5c8-f240-47f6-bf37-ee7c1f7262ac@github.com>

On Thu, 31 Oct 2024 17:11:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinProperties.java line 271:
>> 
>>> 269: 
>>> 270:     // system property utilities
>>> 271:     @SuppressWarnings("removal")
>> 
>> really, this should be in Utils.
>
> Unrelated (but yes, we have several flavors of similar utilities that could be unified in some future cleanup issue).

I wrote all needed helper when marlin was a side-project (plugin), but I totally agree dealing easily with such config files should have been provided by jdk.internals.config classes

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825502434

From lkostyra at openjdk.org  Fri Nov  1 09:37:19 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:19 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v3]
In-Reply-To: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
Message-ID: <St5KBv0lPq6bVG8lZ15z5yg5VhkaluWOHfPkRI681lQ=.1166d90a-a4b2-4002-99ad-cee2929d6f08@github.com>

> This PR removes uses of `AccessControler.doPrivileged()` from `javafx.graphics` package. All uses of `doPrivileged()` were removed _excluding_ `com.sun.javafx.tk` and `com.sun.ui.glass` subpackages - those are handled by [JDK-8342453](https://bugs.openjdk.org/browse/JDK-8342453) (already completed) and [JDK-8342454](https://bugs.openjdk.org/browse/JDK-8342454) respectively.
> 
> Most of these changes are fairly straightforward and follow the standard replacement from `AccessController.doPrivileged(LAMBDA)` to just simply `LAMBDA` with a couple exceptions:
> 
> - `StyleManager.java` where `loadStylesheet()` followed two steps - attempting straightforward stylesheet load via `loadStylesheetUnPrivileged()` and in case of `AccessControlException` retrying the load via `AccessController.doPrivileged` with read-only access to stylesheet JAR. Now that `doPrivileged` is deprecated and not used anymore, `loadStylesheetUnPrivileged()` was always successful and the fallback became essentially dead code. Fallback was removed and `loadStylesheetUnPrivileged()` was renamed to `loadStylesheet()`.
> - `Scene.java` integrates with `com.sun.javafx.tk` so only straightforward `doPrivileged()` calls were removed - `AccessControlContext` remained, as it needs to be removed from both tk and Scene via a follow-up ([JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993))
> 
> Building graphics module now produces less warnings than before this change with no new warning messages (all warnings refer to the use of `Unsafe` which is out of scope of this change).

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

  Review fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1619/files
  - new: https://git.openjdk.org/jfx/pull/1619/files/bd3780cf..43bfbefe

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

  Stats: 39 lines in 9 files changed: 5 ins; 24 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1619/head:pull/1619

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

From lkostyra at openjdk.org  Fri Nov  1 09:37:20 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:20 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <Y7UDFbID4AtX5y8PIgewOs0HmFZWOke-jMfm49fk1fg=.5231c164-5d01-4e76-afeb-5da3690788b9@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <Y7UDFbID4AtX5y8PIgewOs0HmFZWOke-jMfm49fk1fg=.5231c164-5d01-4e76-afeb-5da3690788b9@github.com>
Message-ID: <JbgYfxIqKXDr24P5fGeJGhvlZSN9n0pM1v-_5qMvG-I=.e6f4c193-94b6-49e6-bb89-02ce30428620@github.com>

On Thu, 31 Oct 2024 16:18:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Scene: Remove missed doPrivileged use
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/Disposer.java line 62:
> 
>> 60:             tgn != null;
>> 61:             tg = tgn, tgn = tg.getParent());
>> 62:         Thread t = new Thread(tg, disposerInstance, "Prism Font Disposer");
> 
> very minor: I would have separated `for()` from L62 by a newline.  This `for` is already confusing enough.

Done

> modules/javafx.graphics/src/main/java/com/sun/javafx/util/ModuleHelper.java line 39:
> 
>> 37: 
>> 38:     static {
>> 39:         verbose = Boolean.getBoolean("javafx.verbose");
> 
> minor I would rather moved it to L36

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825613161
PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825622675

From lkostyra at openjdk.org  Fri Nov  1 09:37:20 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:20 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <IvG609wM6VQqb6GlzWjmmX9S2Oxh-vPtoI3r5S8QrHY=.d34992ae-60e9-4afd-aa3c-64ceaae28c1c@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <Y7UDFbID4AtX5y8PIgewOs0HmFZWOke-jMfm49fk1fg=.5231c164-5d01-4e76-afeb-5da3690788b9@github.com>
 <_-fkSD8JfZ3Rq5COeCpGldTBps7N3JnKV-5CwHGnlwk=.bac96475-3ab9-4aa8-91dc-b7c3b3f1b935@github.com>
 <MC3dKNjWcVlcGg8lmU2JJ8DDEfUF-I_j7qTe0JdrsBk=.e3674795-e483-4ef8-bbab-ba4e0ebad2d9@github.com>
 <IvG609wM6VQqb6GlzWjmmX9S2Oxh-vPtoI3r5S8QrHY=.d34992ae-60e9-4afd-aa3c-64ceaae28c1c@github.com>
Message-ID: <WO_xmKCzPqDzq1JPreryXU-WkvtLiKtqgq4r4lbFk0E=.d43ca0f4-5d9b-4c63-8daf-0dc8701b8397@github.com>

On Thu, 31 Oct 2024 23:14:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> well, the original code is just sloppy, but we have a policy of not fixing unrelated issues, or even adding comments pointing out the sloppy code.
>> 
>> in this case, we can probably ignore it - it's probably not worth fixing since it's a debug output.
>
> In this case, I wouldn't mind adding a comment about further follow-up, although I question whether it is worth it. Probably not (so you could just leave it alone).

> I have a separate question: Is the finally statement really needed?

Not really, I think I just repeated the pattern from other similar blocks. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825617862

From lkostyra at openjdk.org  Fri Nov  1 09:37:21 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:21 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <f-v_QKLKEsDAxAN9I0DzTY62GXKEPcQb0K1YfEw7Tvc=.99ffe50c-d956-422a-9f18-367d61849577@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <f-v_QKLKEsDAxAN9I0DzTY62GXKEPcQb0K1YfEw7Tvc=.99ffe50c-d956-422a-9f18-367d61849577@github.com>
Message-ID: <E9UqaPvMMFWY20IqOOKUmxU9TtRb_W8cVtkhtxtdGoE=.1a614eb6-bf7a-462f-b6b3-0379b8c4a29e@github.com>

On Thu, 31 Oct 2024 17:50:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Scene: Remove missed doPrivileged use
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java line 248:
> 
>> 246:                         e.printStackTrace();
>> 247:                     }
>> 248:                 } finally {
> 
> Same comment as above: I'm not sure the `finally` is needed (although it seems not harmful, I don't think it is equivalent in the presence of a thrown `Error`).

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825621082

From lkostyra at openjdk.org  Fri Nov  1 09:37:22 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:22 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <a70cUe4Agft7IvLr6yJ1Weiz6IsGB6tRPdAYMEfW3aQ=.a1e17f12-cab9-4685-8590-52066133db1e@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <iGUtswxnm9S_-8VLbS6H2rc1SOog3BkdyzRr0NfjGBQ=.de5e99fd-7246-4862-832d-0212186fe7a4@github.com>
 <B9X-SedkYFgdhQmZcAZa163-FtWAvbcwO8p-DTSBdoI=.d00e6084-7f58-4880-9fa0-d62801382336@github.com>
 <a70cUe4Agft7IvLr6yJ1Weiz6IsGB6tRPdAYMEfW3aQ=.a1e17f12-cab9-4685-8590-52066133db1e@github.com>
Message-ID: <1UeYQ3mWvyCh0aVgIjsylTfMrLIm5zCQEhJvqwTU2tY=.7eed9cac-618b-4ceb-b0c3-8198d4710d9d@github.com>

On Thu, 31 Oct 2024 18:31:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I would suggest to double check the unused imports and unneeded `@SuppressWarning`s after we are through with the partial changes, in a separate ticket.  Eclipse can be configured to show these as warnings.
>
> Good idea. I also plan to double-check this after the last of the follow-up fixes I do, which will likely be [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).

> After this change there is an unused import of ACCESS_WINDOW_LIST_PERMISSION and the SuppressWarnings annotation is no longer needed.

Done, must've missed it when changing this file.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825623362

From lkostyra at openjdk.org  Fri Nov  1 09:37:24 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:24 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v3]
In-Reply-To: <iGUtswxnm9S_-8VLbS6H2rc1SOog3BkdyzRr0NfjGBQ=.de5e99fd-7246-4862-832d-0212186fe7a4@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <iGUtswxnm9S_-8VLbS6H2rc1SOog3BkdyzRr0NfjGBQ=.de5e99fd-7246-4862-832d-0212186fe7a4@github.com>
Message-ID: <qTbrIra1buhqO_KwK8PVqZhBWZi5nHBhp7B6jzFqPXY=.5bbca3b5-44ca-4bb0-97cc-12dc56259945@github.com>

On Thu, 31 Oct 2024 16:22:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> modules/javafx.graphics/src/main/java/com/sun/marlin/RendererStats.java line 362:
> 
>> 360:         private RendererStatsHolder() {
>> 361:             AccessController.doPrivileged(
>> 362:                 (PrivilegedAction<Void>) () -> {
> 
> There are unused imports after this change.

Done

> modules/javafx.graphics/src/main/java/javafx/scene/PropertyHelper.java line 38:
> 
>> 36:         } catch (Exception any) {
>> 37:         }
>> 38:         return false;
> 
> Following the removal of the doPrivileged call, the second sentence in the comment block of this method -- starting with "Note that ..." -- is wrong and can be removed.

Done

> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1448:
> 
>> 1446:         final AccessControlContext acc = AccessController.getContext();
>> 1447:         snapshotRunnableList.add(() -> {
>> 1448:             AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
> 
> I think that this method has a now-unneeded `SuppressWarnings` annotation.

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825624171
PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825628050
PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825628715

From lkostyra at openjdk.org  Fri Nov  1 09:37:25 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:25 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <SVX6ymemkny565GoSWjLd_njC4dYdeihQmE4ZcMxW7I=.ed7df946-5444-42f9-918b-faa7de8c7c1b@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <SVX6ymemkny565GoSWjLd_njC4dYdeihQmE4ZcMxW7I=.ed7df946-5444-42f9-918b-faa7de8c7c1b@github.com>
Message-ID: <LFby6MpqBZLjEaU-3_Ayr4q2579rNmLjoh0DAQYfIFQ=.1d73e844-ebe7-4d19-9015-a78d01c4be20@github.com>

On Thu, 31 Oct 2024 15:16:00 GMT, Glavo <duke at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Scene: Remove missed doPrivileged use
>
> modules/javafx.graphics/src/main/java/com/sun/prism/es2/GLPixelFormat.java line 35:
> 
>> 33:     private long nativePFInfo;
>> 34:     private static int defaultDepthSize;
>> 35:     private static int defaultBufferSize;
> 
> private static final int defaultDepthSize = Integer.getInteger("prism.glDepthSize", 24);
> private static final int defaultBufferSize = Integer.getInteger("prism.glBufferSize", 32);

Done

> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1445:
> 
>> 1443:         }
>> 1444: 
>> 1445:         snapshotRunnableList.add(() -> {
> 
> snapshotRunnableList.add(runnable);

Done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825624992
PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825628703

From lkostyra at openjdk.org  Fri Nov  1 09:37:26 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 09:37:26 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v2]
In-Reply-To: <CTYtEHvsrEQYbZadmyF27J7OGlFeEq0c5xByXcJIhI4=.f43c3960-1334-4d53-844c-93b9b2bee856@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <SVX6ymemkny565GoSWjLd_njC4dYdeihQmE4ZcMxW7I=.ed7df946-5444-42f9-918b-faa7de8c7c1b@github.com>
 <dDZXGR6f2uDa2J8q_h1pnD5qJz2_CvTmvClQ5ZPUCCs=.eee8401d-63fb-4320-a8fb-b1d8e4702c50@github.com>
 <75SubdyqHzkpjYyzdkALcUE7v0SRUdFUXgKmNj0gCqs=.3df90d18-3e14-4d45-a52e-b8b6be425972@github.com>
 <CTYtEHvsrEQYbZadmyF27J7OGlFeEq0c5xByXcJIhI4=.f43c3960-1334-4d53-844c-93b9b2bee856@github.com>
Message-ID: <CyXhL33mGITrh9uVHfaN4jeLzaieIvx_O6pBSWDAeYc=.2f45cf5a-8c98-4a1c-9e97-bf95b5dde26b@github.com>

On Thu, 31 Oct 2024 23:11:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I agree. That has been available since 1.7. But possibly this code is old enough to pre-date that ..
>
> This code possibly dates from JDK 6. If we want to change it (which we probably should), let's do this as a follow-up, since all of the doPrivileged PRs are intended to be behavior neutral.

Done (there actually even was a comment right above this about support for `lineSeparator()` in core)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825627586

From jhendrikx at openjdk.org  Fri Nov  1 11:43:32 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 1 Nov 2024 11:43:32 GMT
Subject: RFR: 8342627: Create Eclipse project files for jdk.jsobject
In-Reply-To: <pzrxt2ohs0MJHbvjp783G-wcKOPAKKEZHrKTPBGNk3I=.f2bfecfd-cc48-4942-bf6b-8c35ae3cf45b@github.com>
References: <pzrxt2ohs0MJHbvjp783G-wcKOPAKKEZHrKTPBGNk3I=.f2bfecfd-cc48-4942-bf6b-8c35ae3cf45b@github.com>
Message-ID: <ZBv0Eh34lALa_tMqZTOp91fPJdz6yzF7JEbRy0u7XeI=.6a89aade-634e-495c-a575-0e59e0012c3d@github.com>

On Thu, 31 Oct 2024 22:55:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added eclipse project files.
> 
> The project is named `jsobject` instead of jdk.jsobject, similarly to how the other projects are named "base", "controls", ... instead of their full module names.

LGTM

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1621#pullrequestreview-2409923230

From kcr at openjdk.org  Fri Nov  1 12:52:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 12:52:37 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v3]
In-Reply-To: <St5KBv0lPq6bVG8lZ15z5yg5VhkaluWOHfPkRI681lQ=.1166d90a-a4b2-4002-99ad-cee2929d6f08@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <St5KBv0lPq6bVG8lZ15z5yg5VhkaluWOHfPkRI681lQ=.1166d90a-a4b2-4002-99ad-cee2929d6f08@github.com>
Message-ID: <W_pLTZEW99QhXhwe06cCN7aMj4t0k85qsIwPJEREMu8=.6da65b92-8aa7-41d9-ab93-4a12b499d6d3@github.com>

On Fri, 1 Nov 2024 09:37:19 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR removes uses of `AccessControler.doPrivileged()` from `javafx.graphics` package. All uses of `doPrivileged()` were removed _excluding_ `com.sun.javafx.tk` and `com.sun.ui.glass` subpackages - those are handled by [JDK-8342453](https://bugs.openjdk.org/browse/JDK-8342453) (already completed) and [JDK-8342454](https://bugs.openjdk.org/browse/JDK-8342454) respectively.
>> 
>> Most of these changes are fairly straightforward and follow the standard replacement from `AccessController.doPrivileged(LAMBDA)` to just simply `LAMBDA` with a couple exceptions:
>> 
>> - `StyleManager.java` where `loadStylesheet()` followed two steps - attempting straightforward stylesheet load via `loadStylesheetUnPrivileged()` and in case of `AccessControlException` retrying the load via `AccessController.doPrivileged` with read-only access to stylesheet JAR. Now that `doPrivileged` is deprecated and not used anymore, `loadStylesheetUnPrivileged()` was always successful and the fallback became essentially dead code. Fallback was removed and `loadStylesheetUnPrivileged()` was renamed to `loadStylesheet()`.
>> - `Scene.java` integrates with `com.sun.javafx.tk` so only straightforward `doPrivileged()` calls were removed - `AccessControlContext` remained, as it needs to be removed from both tk and Scene via a follow-up ([JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993))
>> 
>> Building graphics module now produces less warnings than before this change with no new warning messages (all warnings refer to the use of `Unsafe` which is out of scope of this change).
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1619#pullrequestreview-2410008691

From kcr at openjdk.org  Fri Nov  1 12:52:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 12:52:38 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v3]
In-Reply-To: <DTLx-PaZrwi-Hr518Wf2hNs59ffv2K5JkP3YOzw5zTg=.227ae5c8-f240-47f6-bf37-ee7c1f7262ac@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com>
 <Y7UDFbID4AtX5y8PIgewOs0HmFZWOke-jMfm49fk1fg=.5231c164-5d01-4e76-afeb-5da3690788b9@github.com>
 <ZjPm5iu5DE4jnm71Au9pBJUjFviH-_Sdw6htlaEcQC8=.e2f64756-3331-464e-9b18-89936facf0d4@github.com>
 <DTLx-PaZrwi-Hr518Wf2hNs59ffv2K5JkP3YOzw5zTg=.227ae5c8-f240-47f6-bf37-ee7c1f7262ac@github.com>
Message-ID: <Nkzilf8eumlDv6wHdJGjYFXyyi0nbh6tDhElmRGKRj8=.d340fc65-6918-4a99-9120-db0813ac7213@github.com>

On Fri, 1 Nov 2024 07:21:34 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Unrelated (but yes, we have several flavors of similar utilities that could be unified in some future cleanup issue).
>
> I wrote all needed helper when marlin was a side-project (plugin), but I totally agree dealing easily with such config files should have been provided by jdk.internals.config classes

We can't use any JDK internals in JavaFX, so if we ever do anything about this, we would create methods in a utility class in a non-exported package in `javafx.base`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1619#discussion_r1825783110

From kcr at openjdk.org  Fri Nov  1 13:43:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 13:43:36 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web
In-Reply-To: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
Message-ID: <O2Q5G0EpSdeh2ikBflEYqoDhjzEjHs_R2rb-EAmVTak=.9781ca7f-7d44-4fc2-b906-118297716774@github.com>

On Thu, 31 Oct 2024 22:51:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.

Looks good except for one problem that needs to be fixed. I also left a question inline about removed comment lines.

@arapte Can you be the second reviewer?

modules/javafx.web/src/main/java/com/sun/webkit/Utilities.java line 119:

> 117:         }
> 118: 
> 119:         return MethodHelper.invoke(method, instance, args);

The removal of the try/catch is causing a test failure in `JavaScriptBridgeTest` because `InvocationTargetException` is now thrown rather than `InvocationTargetException::getCause`.

Suggestion:

        try {
            return MethodHelper.invoke(method, instance, args);
        } catch (InvocationTargetException ex) {
            Throwable cause = ex.getCause();
            throw cause != null ? cause : ex;
        }

modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java line 580:

> 578:                 errorCode = LoadListenerClient.MALFORMED_URL;
> 579:             } catch (@SuppressWarnings("removal") AccessControlException ex) {
> 580:                 errorCode = LoadListenerClient.PERMISSION_DENIED;

Excellent. This was on my list for [JDK-8342998](https://bugs.openjdk.org/browse/JDK-8342998), so one less thing for me to do for that (actually, two less things, since you also took care of the one in `URLLoader.java`).

modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java line 835:

> 833:         @SuppressWarnings("removal")
> 834:         Image icon = AccessController.doPrivileged((PrivilegedAction<Image>) () -> new Image(HTMLEditorSkin.class.getResource(iconName).toString()));
> 835: //        button.setGraphic(new ImageView(icon));

I see you removed this comment. Do you think there is no value in leaving it?

modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java line 861:

> 859:         Image icon = AccessController.doPrivileged((PrivilegedAction<Image>) () -> new Image(HTMLEditorSkin.class.getResource(iconName).toString()));
> 860:         ((StyleableProperty)toggleButton.graphicProperty()).applyStyle(null, new ImageView(icon));
> 861: //        toggleButton.setGraphic(new ImageView(icon));

Same question as above.

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

PR Review: https://git.openjdk.org/jfx/pull/1620#pullrequestreview-2410029043
PR Comment: https://git.openjdk.org/jfx/pull/1620#issuecomment-2451891315
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825816669
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825794129
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825827044
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825827478

From kcr at openjdk.org  Fri Nov  1 13:47:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 13:47:33 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference
In-Reply-To: <v16u8aiIUFVYzQ6n8Ux_xBJl9zohInJpyEblGCMGOCw=.5f20eb7f-8254-48c5-a10d-694ca35a8faf@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <v16u8aiIUFVYzQ6n8Ux_xBJl9zohInJpyEblGCMGOCw=.5f20eb7f-8254-48c5-a10d-694ca35a8faf@github.com>
Message-ID: <dt5P9-Ymq8WbvAmB6QXRNNd9mOHP4PEJvHqgj-sjMLw=.f5f69b81-92da-4c50-9d89-b901d5cd87de@github.com>

On Thu, 31 Oct 2024 18:16:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> My thinking is that a particular preference should be useful and almost universally supported on the desktop platforms to make it into JavaFX API.

This seems like the right criteria to me.

> The number of preferences we might consider are pretty limited, so I don't expect `Platform.Preferences` to explode in size and scope.

Good.

> I think this is a minor addition that doesn't change anything substantial about `Platform.Preferences`, and as such doesn't need a major discussion since the arguments are basically the same since the introduction of platform preferences. However, if you or others are interested in having a discussion, we can of course do that.

With this explanation, I agree.

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

PR Comment: https://git.openjdk.org/jfx/pull/1618#issuecomment-2451896822

From kcr at openjdk.org  Fri Nov  1 13:47:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 13:47:33 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference
In-Reply-To: <wl7ZdosjigApmYMvuSK1Tu0b5DCLsx18ieKE0X0X-TY=.e6194133-ce43-4c4f-855d-036acf42d90c@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <wl7ZdosjigApmYMvuSK1Tu0b5DCLsx18ieKE0X0X-TY=.e6194133-ce43-4c4f-855d-036acf42d90c@github.com>
Message-ID: <nBmQbQVcYu9nNrYXKJNWGUJOa49u2gYJq3ZIuATZnbw=.9bd05c95-1f64-444a-a94c-1e569f5d3ebd@github.com>

On Thu, 31 Oct 2024 17:56:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> This looks like a useful data point.
> 
> I am curious as to what are the criteria for including or excluding a particular preference?  What is our long term goal - should we support all the preferences available on a particular platform, or the intersection, or what?  May be it's something to discuss first on the mailing list.

Reviewers: @andy-goryachev-oracle @lukostyra 

(I'll look over the public API and the CSR)

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

PR Comment: https://git.openjdk.org/jfx/pull/1618#issuecomment-2451898422

From kcr at openjdk.org  Fri Nov  1 13:55:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 13:55:37 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v2]
In-Reply-To: <aT0x7JjWOrmREFmm7brsBZyyXoY4AB6QQu2FtRl-aWQ=.9faebc89-d993-458e-9644-d763968d0a52@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <aT0x7JjWOrmREFmm7brsBZyyXoY4AB6QQu2FtRl-aWQ=.9faebc89-d993-458e-9644-d763968d0a52@github.com>
Message-ID: <McIU5NGgGupQPQ2ayBQytm93h7hFrXMtWBkZPU_5aQA=.5b0a01bb-cabc-402c-bc4e-446f632c0d35@github.com>

On Thu, 31 Oct 2024 20:52:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change reducedScrollBars to persistentScrollBars

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 599:

> 597:          * @since 24
> 598:          */
> 599:         ReadOnlyBooleanProperty persistentScrollBarsProperty();

Do you also plan to add new platform-specific preferences or do you think this is unnecessary?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1825843065

From codebangusllc at gmail.com  Fri Nov  1 14:41:02 2024
From: codebangusllc at gmail.com (David Kopp)
Date: Fri, 1 Nov 2024 09:41:02 -0500
Subject: ApplicationMenu pull request
Message-ID: <0A65E282-1890-4908-903A-1DE27A275313@gmail.com>

I have created a pull request for the ApplicationMenu code I have been working on. This pull request only contains support for macOS. While later version of GTK support similar functionality, there is no support for it in the existing JavaFX codebase.

I believe someone with the proper access needs to create an issue for this?

Have a blessed day,



David Kopp

From angorya at openjdk.org  Fri Nov  1 14:43:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 14:43:38 GMT
Subject: RFR: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other [v3]
In-Reply-To: <St5KBv0lPq6bVG8lZ15z5yg5VhkaluWOHfPkRI681lQ=.1166d90a-a4b2-4002-99ad-cee2929d6f08@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
 <St5KBv0lPq6bVG8lZ15z5yg5VhkaluWOHfPkRI681lQ=.1166d90a-a4b2-4002-99ad-cee2929d6f08@github.com>
Message-ID: <_21wU163cKNnQ4EHZm0XWYV11WrkLgLlcicmTSIXPNk=.3cbd52ea-6abb-48f5-a521-a61fbad1d259@github.com>

On Fri, 1 Nov 2024 09:37:19 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR removes uses of `AccessControler.doPrivileged()` from `javafx.graphics` package. All uses of `doPrivileged()` were removed _excluding_ `com.sun.javafx.tk` and `com.sun.ui.glass` subpackages - those are handled by [JDK-8342453](https://bugs.openjdk.org/browse/JDK-8342453) (already completed) and [JDK-8342454](https://bugs.openjdk.org/browse/JDK-8342454) respectively.
>> 
>> Most of these changes are fairly straightforward and follow the standard replacement from `AccessController.doPrivileged(LAMBDA)` to just simply `LAMBDA` with a couple exceptions:
>> 
>> - `StyleManager.java` where `loadStylesheet()` followed two steps - attempting straightforward stylesheet load via `loadStylesheetUnPrivileged()` and in case of `AccessControlException` retrying the load via `AccessController.doPrivileged` with read-only access to stylesheet JAR. Now that `doPrivileged` is deprecated and not used anymore, `loadStylesheetUnPrivileged()` was always successful and the fallback became essentially dead code. Fallback was removed and `loadStylesheetUnPrivileged()` was renamed to `loadStylesheet()`.
>> - `Scene.java` integrates with `com.sun.javafx.tk` so only straightforward `doPrivileged()` calls were removed - `AccessControlContext` remained, as it needs to be removed from both tk and Scene via a follow-up ([JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993))
>> 
>> Building graphics module now produces less warnings than before this change with no new warning messages (all warnings refer to the use of `Unsafe` which is out of scope of this change).
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

thank you for making the changes!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1619#pullrequestreview-2410206274

From lkostyra at openjdk.org  Fri Nov  1 14:52:45 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 1 Nov 2024 14:52:45 GMT
Subject: Integrated: 8342456: Remove calls to doPrivileged in
 javafx.graphics/other
In-Reply-To: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
References: <OfVGKPWAxYShXlFAGKv9GBR1RGLgoveQxUjQ5SQLioQ=.1df10a5b-1e48-46e3-84f1-b0ae836f5202@github.com>
Message-ID: <HdQ6IxMmk7ibyCBA4RCjYSLMrTzZl_CNkLq5H4fIH6Q=.a493d78c-ec43-4c39-9c2b-f388e2ebe8fe@github.com>

On Thu, 31 Oct 2024 13:55:45 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This PR removes uses of `AccessControler.doPrivileged()` from `javafx.graphics` package. All uses of `doPrivileged()` were removed _excluding_ `com.sun.javafx.tk` and `com.sun.ui.glass` subpackages - those are handled by [JDK-8342453](https://bugs.openjdk.org/browse/JDK-8342453) (already completed) and [JDK-8342454](https://bugs.openjdk.org/browse/JDK-8342454) respectively.
> 
> Most of these changes are fairly straightforward and follow the standard replacement from `AccessController.doPrivileged(LAMBDA)` to just simply `LAMBDA` with a couple exceptions:
> 
> - `StyleManager.java` where `loadStylesheet()` followed two steps - attempting straightforward stylesheet load via `loadStylesheetUnPrivileged()` and in case of `AccessControlException` retrying the load via `AccessController.doPrivileged` with read-only access to stylesheet JAR. Now that `doPrivileged` is deprecated and not used anymore, `loadStylesheetUnPrivileged()` was always successful and the fallback became essentially dead code. Fallback was removed and `loadStylesheetUnPrivileged()` was renamed to `loadStylesheet()`.
> - `Scene.java` integrates with `com.sun.javafx.tk` so only straightforward `doPrivileged()` calls were removed - `AccessControlContext` remained, as it needs to be removed from both tk and Scene via a follow-up ([JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993))
> 
> Building graphics module now produces less warnings than before this change with no new warning messages (all warnings refer to the use of `Unsafe` which is out of scope of this change).

This pull request has now been integrated.

Changeset: 58cd76a8
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/58cd76a838542cc20e0ef2e880d18fa762664172
Stats:     1225 lines in 51 files changed: 59 ins; 702 del; 464 mod

8342456: Remove calls to doPrivileged in javafx.graphics/other

Reviewed-by: kcr, angorya

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

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

From angorya at openjdk.org  Fri Nov  1 15:01:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 15:01:10 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v2]
In-Reply-To: <O2Q5G0EpSdeh2ikBflEYqoDhjzEjHs_R2rb-EAmVTak=.9781ca7f-7d44-4fc2-b906-118297716774@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <O2Q5G0EpSdeh2ikBflEYqoDhjzEjHs_R2rb-EAmVTak=.9781ca7f-7d44-4fc2-b906-118297716774@github.com>
Message-ID: <Jmwm8GC2MjTxCqxgFyOhr52SpJAhSWv4Fgr1dhm1rKw=.5338af2b-cfe3-44a8-a29f-a159beb50baa@github.com>

On Fri, 1 Nov 2024 13:26:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.web/src/main/java/com/sun/webkit/Utilities.java line 119:
> 
>> 117:         }
>> 118: 
>> 119:         return MethodHelper.invoke(method, instance, args);
> 
> The removal of the try/catch is causing a test failure in `JavaScriptBridgeTest` because `InvocationTargetException` is now thrown rather than `InvocationTargetException::getCause`.
> 
> Suggestion:
> 
>         try {
>             return MethodHelper.invoke(method, instance, args);
>         } catch (InvocationTargetException ex) {
>             Throwable cause = ex.getCause();
>             throw cause != null ? cause : ex;
>         }

changed as suggested.
is this test being run as part of GHA or the headful test suite?

> modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java line 835:
> 
>> 833:         @SuppressWarnings("removal")
>> 834:         Image icon = AccessController.doPrivileged((PrivilegedAction<Image>) () -> new Image(HTMLEditorSkin.class.getResource(iconName).toString()));
>> 835: //        button.setGraphic(new ImageView(icon));
> 
> I see you removed this comment. Do you think there is no value in leaving it?

reverted here and below.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825919662
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1825918199

From angorya at openjdk.org  Fri Nov  1 15:01:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 15:01:10 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v2]
In-Reply-To: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
Message-ID: <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>

> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1620/files
  - new: https://git.openjdk.org/jfx/pull/1620/files/ee1a9bfe..1c1e8eab

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

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

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

From kcr at openjdk.org  Fri Nov  1 16:02:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 16:02:40 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v2]
In-Reply-To: <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>
Message-ID: <FaFMhYrbBOMmEQDhLuIN9XHGX0SAGNhlFt7ctNMwUmU=.5da4064b-539f-444f-a975-81c47654c0da@github.com>

On Fri, 1 Nov 2024 15:01:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1620#pullrequestreview-2410357383

From kcr at openjdk.org  Fri Nov  1 17:02:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 17:02:36 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v11]
In-Reply-To: <vzY0ciJ9SVtNBwWsFkD-2D4jztX5mS1Q2wUuLjbEaKQ=.a6df9eaa-6800-4ccb-a105-9c45205f5b9f@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <vzY0ciJ9SVtNBwWsFkD-2D4jztX5mS1Q2wUuLjbEaKQ=.a6df9eaa-6800-4ccb-a105-9c45205f5b9f@github.com>
Message-ID: <EAe8zn76ie4KNu0LXHvyRO9AAyX-1iCkTaw3eNAbLT8=.af1eb031-5b35-4914-896a-94d2c1fb1431@github.com>

On Thu, 31 Oct 2024 15:42:56 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/ximageloader
>  - review comments
>  - Merge branch 'master' into feature/ximageloader
>  - Merge branch 'master' into feature/ximageloader
>  - review changes
>  - scanline stride always measured in bytes
>  - remove unused code
>  - fix line endings
>  - fix line endings
>  - add support for palette-based image formats
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/7ec744a2...ed478762

I'm just starting to look at this. The tests I ran look good so far, with two things to note:

1. If `XImageLoaderFactory` fails to load, it with throw an `Error` that terminates the app. I left a comment and suggestion inline.
2. This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.

modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 633:

> 631:                 Class<?> factoryClass = Class.forName("com.sun.javafx.iio.javax.XImageLoaderFactory");
> 632:                 xImageLoaderFactory = Optional.of((ImageLoaderFactory)factoryClass.getMethod("getInstance").invoke(null));
> 633:             } catch (ReflectiveOperationException e) {

This looks like a good approach. I simulated a failure (by adding a dependency on an unrelated module that was there at compile time, but I excluded at runtime) and it gets a `NoClassDefFoundError`.

Suggestion:

            } catch (NoClassDefFoundError | ReflectiveOperationException e) {

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

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2410484943
PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1826059863

From kcr at openjdk.org  Fri Nov  1 17:11:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 17:11:35 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v9]
In-Reply-To: <pF4xOubINVq6KeWQ7drJgL66NKSYElljwSS0l4P_x8g=.46318a78-5442-445f-b8d3-24d719b68e7f@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <OQHbfK3dYnifuKbu-e1BtYFQm1_kr0jqBKIhKaULWpM=.8f7efd86-444b-48d1-9fb9-4bb28e0d422b@github.com>
 <OPpjAsRm3v4o7ogGzdYeBdZEK62Q8JmZxSw5K3HmVXs=.ef43d2cf-bf7e-4134-875f-0b8b7b732ea1@github.com>
 <pF4xOubINVq6KeWQ7drJgL66NKSYElljwSS0l4P_x8g=.46318a78-5442-445f-b8d3-24d719b68e7f@github.com>
Message-ID: <DXauCjrtBb6tl3OqP3Snsjlr1o5vxBUR2OgpwaOHrtY=.cdb3332d-586c-4f2c-b296-652199b9ff37@github.com>

On Wed, 30 Oct 2024 18:32:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/bmp/BMPImageLoaderFactory.java line 496:
>> 
>>> 494: 
>>> 495:         int[] outWH = ImageTools.computeDimensions(
>>> 496:             bih.biWidth, hght, (int)(w * imagePixelScale), (int)(h * imagePixelScale), preserveAspectRatio);
>> 
>> I see possibility of these calculations overflowing.
>
> `ImageTools.computeDimensions()` will not allow the dimensions to be less than 0.

An integer overflow doesn't necessarily cause the result to be negative. I echo Jay's comment, and suggest an explicit check. I note that the code already does that below but doesn't take `pixelScale` into account.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1826073649

From angorya at openjdk.org  Fri Nov  1 17:28:22 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 17:28:22 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v34]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <lJb0kecOZJUx3PjWTYWpVCiM5900VCztdUQ1NAUSZww=.8dbc2486-6b55-448e-8e39-c4536a5eb014@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - validate model
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - review comments
 - measurement node
 - review comments 1
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - break iterator
 - consume conditionally
 - ... and 38 more: https://git.openjdk.org/jfx/compare/58cd76a8...48086f79

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=33
  Stats: 39718 lines in 206 files changed: 39704 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Fri Nov  1 17:40:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 17:40:02 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  input map

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/48086f79..189c6633

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=34
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=33-34

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

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

From angorya at openjdk.org  Fri Nov  1 17:45:55 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 17:45:55 GMT
Subject: RFR: 8342911: Remove calls to doPrivileged in controls [v3]
In-Reply-To: <fahJxT0pelJqcaMh_bIios9JVLEgwpvTeG1CV71GTcQ=.a2255c7a-1269-454a-adb9-23ce15ab1f0e@github.com>
References: <fahJxT0pelJqcaMh_bIios9JVLEgwpvTeG1CV71GTcQ=.a2255c7a-1269-454a-adb9-23ce15ab1f0e@github.com>
Message-ID: <sMitwKVlTk_5VaeD93WXnP-wK9sEnwZYyzdArG5VTHY=.356f6a1c-51de-473e-9fec-74b8839fa307@github.com>

> Removes doPrivileged in the following module:
> 
> - javafx.controls
> 
> See JDK-8342441 for details.
> 
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.

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 8342911.do.priviliged.controls
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342911.do.priviliged.controls
 - 8342911: Remove calls to doPrivileged in controls

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1615/files
  - new: https://git.openjdk.org/jfx/pull/1615/files/5511ac11..c94df6ab

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

  Stats: 2516 lines in 82 files changed: 186 ins; 1236 del; 1094 mod
  Patch: https://git.openjdk.org/jfx/pull/1615.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1615/head:pull/1615

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

From mstrauss at openjdk.org  Fri Nov  1 17:45:59 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 17:45:59 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v3]
In-Reply-To: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
Message-ID: <DfWyG8rdeQw4DwR9MNNrdu5HrJqzCQ11RO8CUXoBbEQ=.24008d9e-f477-41d8-b7e0-4aad8bb59c28@github.com>

> This PR adds another accessibility preference that is available on all supported desktop platforms:
> 
> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
> 
> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.

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

  add platform keys to javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1618/files
  - new: https://git.openjdk.org/jfx/pull/1618/files/bd6ecbce..00de674f

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

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

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

From mstrauss at openjdk.org  Fri Nov  1 17:45:59 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 17:45:59 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v2]
In-Reply-To: <McIU5NGgGupQPQ2ayBQytm93h7hFrXMtWBkZPU_5aQA=.5b0a01bb-cabc-402c-bc4e-446f632c0d35@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <aT0x7JjWOrmREFmm7brsBZyyXoY4AB6QQu2FtRl-aWQ=.9faebc89-d993-458e-9644-d763968d0a52@github.com>
 <McIU5NGgGupQPQ2ayBQytm93h7hFrXMtWBkZPU_5aQA=.5b0a01bb-cabc-402c-bc4e-446f632c0d35@github.com>
Message-ID: <hKpZ9mPxae69J1b9-Ti4-ZLphlHjb6JacNAbrY4lQJ0=.0300a377-5d31-42d6-9625-f51558c4e7f2@github.com>

On Fri, 1 Nov 2024 13:51:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change reducedScrollBars to persistentScrollBars
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 599:
> 
>> 597:          * @since 24
>> 598:          */
>> 599:         ReadOnlyBooleanProperty persistentScrollBarsProperty();
> 
> Do you also plan to add new platform-specific preferences or do you think this is unnecessary?

I added the respective platform-specific keys to the `Preferences` documentation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1826117375

From mstrauss at openjdk.org  Fri Nov  1 18:03:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 18:03:56 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v12]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <DpRKAa2Q83gSLSrAArVTLaq2GVxcS5OsNlLdNvG4ZIg=.894c197e-5ef5-4b8a-b2b4-155e5f116024@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

  catch NoClassDefFoundError
  
  Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1593/files
  - new: https://git.openjdk.org/jfx/pull/1593/files/ed478762..c5fdd298

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

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

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

From kcr at openjdk.org  Fri Nov  1 21:36:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 21:36:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
Message-ID: <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>

On Fri, 1 Nov 2024 17:40:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   input map

I think you addressed all of my earlier comments. I left a few comments and questions inline.

build.gradle line 5996:

> 5994:                 moduleProjList.each { project ->
> 5995:                     if (project.hasProperty("moduleName") && project.buildModule) {
> 5996:                         def incubating = project.hasProperty("incubating") && project.ext.incubating

After the merge of master, you can remove this (it is unused). I removed it from the PR #1616 (Support JavaFX incubator modules).

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/Params.java line 102:

> 100: 
> 101:     /** default preferred height */
> 102:     public static final double PREF_HEIGHT = 176; // matches TextArea

I see `181` as TextArea height, at least on Windows. I think it is computed from the default number of columns visible. I didn't check on macOS.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/Params.java line 105:

> 103: 
> 104:     /** default preferred width */
> 105:     public static final double PREF_WIDTH = 176; // matches TextArea

I see `478` for TextArea width on Windows.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 73:

> 71:  * <h2>Usage Considerations</h2>
> 72:  * {@code CodeArea} extends the {@link RichTextArea} class, meaning most of the functionality is expected to continue
> 73:  * working.  There are some differences that should be mentioned:

Suggestion: "... meaning most of the functionality works as it does in the base class" or similar?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 78:

> 76:  * {@link #applyStyle(TextPos, TextPos, jfx.incubator.scene.control.richtext.model.StyleAttributeMap) applyStyle()},
> 77:  * will be ignored
> 78:  * <li>Line numbers: the line numbers are provided by setting the {@link #leftDecoratorProperty()}

This could be misconstrued to mean that the app should set the `leftDecoratorProperty` to provide line numbers. I would reword it to make it clear that CodeArea itself sets  `leftDecoratorProperty` so applications should not.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 695:

> 693:     /**
> 694:      * Validates the model property value.
> 695:      * The subclass should override this method to check if the model type is supported and throw a TBD if not.

"TBD" --> "IllegalArgumentException".

Also, you might want to add something like: "... should override this method if it restricts the type of model that is supported ..." (since a subclass that takes all types of model need not override it).

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 696:

> 694:      * Validates the model property value.
> 695:      * The subclass should override this method to check if the model type is supported and throw a TBD if not.
> 696:      * A {@code null} value should never generate the exception.

"the exception" --> "an exception".

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/TextPos.java line 71:

> 69:      * @return the instance of {@code TextPos}
> 70:      */
> 71:     public static TextPos ofLeading(int index, int offset) {

Do you also plan to add an  `ofTrailing` convenience method?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 68:

> 66:         /**
> 67:          * This method is called to insert a single text segment at the given position.
> 68:          * The caller guarantees that this method is only called when the content is writable.

Since this is a public method that could be called by an application, I think you still need to describe what happens if the caller does call when not writable.

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

PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2410673583
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826237458
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826292217
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826293494
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826311789
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826313077
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826166666
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826167717
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826181722
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826175861

From kcr at openjdk.org  Fri Nov  1 21:36:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 21:36:37 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v28]
In-Reply-To: <g_0NpcrWZWNlkkFRoEguhEPsBtEbHI9PCmxrrr-Qwxk=.ef4f2372-4781-48d2-a74c-0f8e94de7fe0@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <owbiGHujXQ5Da1gRvEP_RcWQ_se2IX7TDSOgJa7djCY=.83f29dae-3665-427b-bc83-3e8804c6ea5e@github.com>
 <2w75n5akpAwuxEXHyW4TuhkaOKmpqsh6tYMFcirZ88c=.1bff67c5-4e7d-468b-a0ce-1cc7b9d86e9e@github.com>
 <g_0NpcrWZWNlkkFRoEguhEPsBtEbHI9PCmxrrr-Qwxk=.ef4f2372-4781-48d2-a74c-0f8e94de7fe0@github.com>
Message-ID: <BrSFZBD0zPOIEt786ZFoDrlgcuCtuaP_Ysleog7Gm48=.ce94240a-b465-4b82-8bc7-a63df2048d81@github.com>

On Tue, 29 Oct 2024 19:38:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/TextPos.java line 34:
>> 
>>> 32:  * For that, use {@link Marker}.
>>> 33:  */
>>> 34: public final class TextPos implements Comparable<TextPos> {
>> 
>> Remind me why this isn't a record? It seems like it could be, unless I'm missing something.
>
> it could be.  
> 
> does it absolutely have to be?  the class is final, and we have greater flexibility in naming the accessors than with a record, not that we use it here.

A record seems more natural here, so would be the default choice, but if there is a good reason not to, I don't see it as a requirement.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826181164

From kevin.rushforth at oracle.com  Fri Nov  1 22:17:58 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 1 Nov 2024 15:17:58 -0700
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
Message-ID: <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>

I'm restarting the discussion from an earlier thread [0], along with a 
PR to get the support for JavaFX incubator modules integrated ahead of 
any particular feature that might use them.

JEP 11 [1] defines a process for delivering non-final JDK APIs in 
incubator modules.

Similarly, some JavaFX APIs would benefit from spending a period of time 
in a JavaFX release prior to being deemed stable. I propose JavaFX 
incubator modules as a means of putting non-final API in the hands of 
developers, while the API progresses towards either finalization or 
removal in a future release. This is especially useful for complex 
features with a large API surface.

The JavaFX proposal is largely the same as the JDK one, but has some 
important differences that are listed in the JEP.

Please take a look at the updated proposal [2] and PR 1616 [3] that adds 
the needed support for incubator modules.

I have also created a Draft PR [4] with an example module, for 
illustrative purposes only, to show how this might work. This Draft PR 
is based on PR 1616.

Please reply to this message with any feedback, or add PR comments in PR 
1616.

Thank you.

-- Kevin

[0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
[1] https://openjdk.org/jeps/11
[2] 
https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
[4] https://github.com/openjdk/jfx/pull/1616
[5] https://github.com/openjdk/jfx/pull/1617


From kcr at openjdk.org  Fri Nov  1 22:22:07 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 22:22:07 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
Message-ID: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>

This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:

1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
2. A utility class to produce warnings when first using an incubator module.
3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.

See PR #1617 for a sample module that is built on top of this PR's source branch.

This is almost ready to review. I will take it out of Draft in the next day or so.

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

Commit messages:
 - Remove call to doPrivileged
 - 8309381: Support JavaFX incubator modules

Changes: https://git.openjdk.org/jfx/pull/1616/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309381
  Stats: 173 lines in 4 files changed: 169 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1616.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1616/head:pull/1616

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

From kcr at openjdk.org  Fri Nov  1 22:22:07 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Nov 2024 22:22:07 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
In-Reply-To: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
Message-ID: <riTQd_B8vj4YrU7qDIgtSDCuE1MEhcxuGyepAGkt_Yc=.01a9f3e9-5d9b-478c-9658-a19d9c437861@github.com>

On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
> 
> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
> 2. A utility class to produce warnings when first using an incubator module.
> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
> 
> See PR #1617 for a sample module that is built on top of this PR's source branch.
> 
> This is almost ready to review. I will take it out of Draft in the next day or so.

@andy-goryachev-oracle @arapte Can you review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2452663923

From mstrauss at openjdk.org  Fri Nov  1 22:23:15 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 22:23:15 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v13]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <JfiIiFeKVqwbVytEpBcNXgLZ61QqQ1xhYDpunzNugFw=.cb29f484-ac5a-402f-919e-475d9e907213@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

  validate max image width/height

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1593/files
  - new: https://git.openjdk.org/jfx/pull/1593/files/c5fdd298..e9f20df3

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

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

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

From mstrauss at openjdk.org  Fri Nov  1 22:26:33 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 22:26:33 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v9]
In-Reply-To: <DXauCjrtBb6tl3OqP3Snsjlr1o5vxBUR2OgpwaOHrtY=.cdb3332d-586c-4f2c-b296-652199b9ff37@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <OQHbfK3dYnifuKbu-e1BtYFQm1_kr0jqBKIhKaULWpM=.8f7efd86-444b-48d1-9fb9-4bb28e0d422b@github.com>
 <OPpjAsRm3v4o7ogGzdYeBdZEK62Q8JmZxSw5K3HmVXs=.ef43d2cf-bf7e-4134-875f-0b8b7b732ea1@github.com>
 <pF4xOubINVq6KeWQ7drJgL66NKSYElljwSS0l4P_x8g=.46318a78-5442-445f-b8d3-24d719b68e7f@github.com>
 <DXauCjrtBb6tl3OqP3Snsjlr1o5vxBUR2OgpwaOHrtY=.cdb3332d-586c-4f2c-b296-652199b9ff37@github.com>
Message-ID: <B1K9GRIqfDWeEh6ABdrlF4OYT0fxZdaVwdEwUIzJT3k=.7ab95146-9db3-4da7-b284-7c5889115fb1@github.com>

On Fri, 1 Nov 2024 17:03:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> `ImageTools.computeDimensions()` will not allow the dimensions to be less than 0.
>
> An integer overflow doesn't necessarily cause the result to be negative. I echo Jay's comment, and suggest an explicit check. I note that the code already does that below but doesn't take `pixelScale` into account.

I've added `ImageTools.validateMaxDimensions()` to check that both width and height, as well as the byte array that later holds the image data doesn't exceed an int in size.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1826344473

From angorya at openjdk.org  Fri Nov  1 22:44:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 22:44:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
 <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
Message-ID: <HGkdKXdMr9feSQx2V417AZFVYYkRgZU8feK_CPd14PY=.f35b3af5-1ef3-4604-8183-227c13bf6cc0@github.com>

On Fri, 1 Nov 2024 18:49:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   input map
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/TextPos.java line 71:
> 
>> 69:      * @return the instance of {@code TextPos}
>> 70:      */
>> 71:     public static TextPos ofLeading(int index, int offset) {
> 
> Do you also plan to add an  `ofTrailing` convenience method?

not necessary - this case is more complex and is covered by the constructor.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826352014

From angorya at openjdk.org  Fri Nov  1 22:47:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 22:47:37 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
 <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
Message-ID: <oQJS_91Z_UwphN385SDgPfsdaJNqK22YQOvN4ETUGAI=.668bd02c-bfd6-41f5-9412-282911eda8c5@github.com>

On Fri, 1 Nov 2024 20:58:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   input map
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/Params.java line 102:
> 
>> 100: 
>> 101:     /** default preferred height */
>> 102:     public static final double PREF_HEIGHT = 176; // matches TextArea
> 
> I see `181` as TextArea height, at least on Windows. I think it is computed from the default number of columns visible. I didn't check on macOS.

it is not the goal to match the `TextArea`, especially if the latter is different on different platforms.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826353095

From angorya at openjdk.org  Fri Nov  1 22:52:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 22:52:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
 <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
Message-ID: <sQbUWJWF98EnbszeQQrb1kLd6pLuMuXMfHEr-qu3P2g=.4ef55a86-7454-43b4-beae-0a5504bcadf8@github.com>

On Fri, 1 Nov 2024 19:50:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   input map
>
> build.gradle line 5996:
> 
>> 5994:                 moduleProjList.each { project ->
>> 5995:                     if (project.hasProperty("moduleName") && project.buildModule) {
>> 5996:                         def incubating = project.hasProperty("incubating") && project.ext.incubating
> 
> After the merge of master, you can remove this (it is unused). I removed it from the PR #1616 (Support JavaFX incubator modules).

I plan to update (merge) the build script once #1616 is integrated.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826354853

From angorya at openjdk.org  Fri Nov  1 22:58:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 22:58:37 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35]
In-Reply-To: <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <xlBaINON_sWZNKL95l36PE7VblDyp1dlW2Hm5nQSiYU=.5f3eaa2f-74d2-4592-aa21-3eafd57a8548@github.com>
 <wBIHMgCpw84bvQQhC3ikY0-2EGUByyrYuDsbZUE0Rdc=.135ab073-613b-4751-827d-28ac5e1da5ee@github.com>
Message-ID: <bx8qQzgTybJ5upwUz6Qd6Ihdc4_Yl9JxiYVJInDdDpE=.caddc30f-6504-4622-b9cf-cd972058b924@github.com>

On Fri, 1 Nov 2024 18:42:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   input map
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 68:
> 
>> 66:         /**
>> 67:          * This method is called to insert a single text segment at the given position.
>> 68:          * The caller guarantees that this method is only called when the content is writable.
> 
> Since this is a public method that could be called by an application, I think you still need to describe what happens if the caller does call when not writable.

the implementor of the `Content` can do whatever they want - I don't think we should specify that.  In this case, I think it's important to mention that the caller (the `BasicTextModel`) will never do.

maybe `caller` -> `BasicTextModel`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1826361933

From angorya at openjdk.org  Fri Nov  1 23:12:58 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Nov 2024 23:12:58 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v36]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <vd-oi9l8L4CE0jfbCu4VEJwY2iMWBEJqHnBgl2-TURM=.a4cf642a-91e2-4845-8510-7cc0ba1d320c@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/189c6633..39463070

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=35
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=34-35

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

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

From michaelstrau2 at gmail.com  Fri Nov  1 23:19:14 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 2 Nov 2024 00:19:14 +0100
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
Message-ID: <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>

I think it should be made clear that incubation is not an alternative
to, or a path around community concensus. Specifically, I'm looking at
the RichTextArea proposal, which seems to also incubate the InputMap
proposal. If we accepted the incubation of incidental features without
community concensus, then surely at some point in the future, we'd be
discussing that we now must commit to a controversial incidental
feature because the momentum is too strong, or because we'd be
breaking code of too many users that are already using the new
features. Any discussion around promoting the main incubating feature
to API, and dropping incidental features will be tainted with
real-world usage arguments.

From mstrauss at openjdk.org  Fri Nov  1 23:38:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 23:38:52 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
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: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>

> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
> 
> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
> 
> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
> 
> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
> 
> This is how it looks like on each of the three operating systems:
> 
> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
> 
> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
> 
> ## Usage
> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
> 
> public class MyApp extends Application {
>     @Override
>     public void start(Stage stage) {
>         var headerBar = new HeaderBar();
>         headerBar.setCenter(new TextField());
> 
>         var root = new BorderPane();
>         root.setTop(headerBar);
> 
>         stage.setScene(new Scene(root));
>         stage.initStyle(StageStyle.EXTENDED);
>         stage.show();
>     }
> }
> 
> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
> 
> ## Platform integration
> The implementation varies per platform, and ranges from pretty easy to quite involved:
> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSWindowStyleMaskFullSizeContentView` flag. A click-and-drag operation is ini...

Michael Strau? 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 feature/extended-window
 - Merge branch 'master' into feature/extended-window
 - macOS: dynamically adapt toolbar style to headerbar height
 - fix header bar height flicker
 - NPE
 - fix peer access outside of synchronizer
 - improve title text documentation
 - macOS: hide window title
 - better documentation
 - set minHeight to native height of title bar
 - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=18
  Stats: 4913 lines in 61 files changed: 4399 ins; 409 del; 105 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 Nov  1 23:39:08 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 23:39:08 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v14]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <dYfpjFhEbSQkvYaI64ZTWV0jw8jV9G7iNAgROT6igNg=.a7026cab-c705-4b43-9f9c-839fe15aad30@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

 - Merge branch 'master' into feature/ximageloader
 - validate max image width/height
 - catch NoClassDefFoundError
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - Merge branch 'master' into feature/ximageloader
 - review comments
 - Merge branch 'master' into feature/ximageloader
 - Merge branch 'master' into feature/ximageloader
 - review changes
 - scanline stride always measured in bytes
 - remove unused code
 - ... and 16 more: https://git.openjdk.org/jfx/compare/58cd76a8...2900ef0a

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

Changes: https://git.openjdk.org/jfx/pull/1593/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=13
  Stats: 3834 lines in 37 files changed: 3033 ins; 632 del; 169 mod
  Patch: https://git.openjdk.org/jfx/pull/1593.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1593/head:pull/1593

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

From mstrauss at openjdk.org  Fri Nov  1 23:39:51 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 1 Nov 2024 23:39:51 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v4]
In-Reply-To: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
Message-ID: <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>

> This PR adds another accessibility preference that is available on all supported desktop platforms:
> 
> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
> 
> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into feature/accessibility-hide-scrollbars
 - add platform keys to javadoc
 - Change reducedScrollBars to persistentScrollBars
 - Add reducedScrollBars preference

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1618/files
  - new: https://git.openjdk.org/jfx/pull/1618/files/00de674f..dc0eac58

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

  Stats: 2492 lines in 79 files changed: 167 ins; 1235 del; 1090 mod
  Patch: https://git.openjdk.org/jfx/pull/1618.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1618/head:pull/1618

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

From mstrauss at openjdk.org  Sat Nov  2 05:02:20 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 2 Nov 2024 05:02:20 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v15]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

  revert doc change

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1593/files
  - new: https://git.openjdk.org/jfx/pull/1593/files/2900ef0a..ce1c359a

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

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

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

From mstrauss at openjdk.org  Sat Nov  2 05:48:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 2 Nov 2024 05:48:14 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v5]
In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
Message-ID: <i-O6vAZwXbepWIeeWjQOkWNoiNvyqpDkQLf7HRhOSvs=.1785468e-2bb6-49f3-b60c-d302fbee715b@github.com>

> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
> 
> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)).
> 
> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change.

Michael Strau? 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 feature/sealed-classes
 - add comment
 - Merge branch 'master' into feature/sealed-classes
 - remove documentation
 - Seal Node, Camera, LightBase, Shape, Shape3D

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1556/files
  - new: https://git.openjdk.org/jfx/pull/1556/files/8332d7e9..4d3ba394

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

  Stats: 6598 lines in 205 files changed: 1677 ins; 3490 del; 1431 mod
  Patch: https://git.openjdk.org/jfx/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556

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

From john.hendrikx at gmail.com  Sun Nov  3 15:46:18 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 3 Nov 2024 16:46:18 +0100
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
Message-ID: <9a4fbe92-b831-421c-a1ef-c15322716b8f@gmail.com>

I can only second this.? I haven't looked at the RichTextArea, but find 
it extremely odd to hear that it also includes part of the input map 
proposal instead of just a new Control/Skin/Behavior.? Any changes to 
how input maps work should be a separate proposal and PR.

--John

On 02/11/2024 00:19, Michael Strau? wrote:
> I think it should be made clear that incubation is not an alternative
> to, or a path around community concensus. Specifically, I'm looking at
> the RichTextArea proposal, which seems to also incubate the InputMap
> proposal. If we accepted the incubation of incidental features without
> community concensus, then surely at some point in the future, we'd be
> discussing that we now must commit to a controversial incidental
> feature because the momentum is too strong, or because we'd be
> breaking code of too many users that are already using the new
> features. Any discussion around promoting the main incubating feature
> to API, and dropping incidental features will be tainted with
> real-world usage arguments.

From psadhukhan at openjdk.org  Mon Nov  4 07:13:34 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Nov 2024 07:13:34 GMT
Subject: RFR: 8342457: Remove calls to doPrivileged in swing [v2]
In-Reply-To: <k3IHre9B2In0Y77TaDuzzszKTrjNUGJMhQkfxHr8E1Q=.3fa0bd34-b9d5-4849-ad48-55b05ea0cc07@github.com>
References: <DYLhrFEtLin2F5YO_PVBJgpj5Pu40SsirpE2yBfWivU=.7e439fcd-941a-451a-a7b9-62ef244f63af@github.com>
 <k3IHre9B2In0Y77TaDuzzszKTrjNUGJMhQkfxHr8E1Q=.3fa0bd34-b9d5-4849-ad48-55b05ea0cc07@github.com>
Message-ID: <iQ0j1yBXM-HehIZf725XRDwgPW-Rago-f-HxHlm91V0=.53b0f15f-700d-4122-93dd-de52c966dfa8@github.com>

On Wed, 30 Oct 2024 18:21:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes doPrivileged in the following module:
>> 
>> - javafx.swing
>> 
>> See JDK-8342441 for details.
>> 
>> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.
>
> 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 five additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342457.do.privileged.swing
>  - Merge remote-tracking branch 'origin/master' into 8342457.do.privileged.swing
>  - 2024
>  - 8342457: Remove calls to doPrivileged in swing

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1613#pullrequestreview-2412292523

From tsayao at openjdk.org  Mon Nov  4 11:31:40 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 4 Nov 2024 11:31:40 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
Message-ID: <yhTB2Rk5373sOC31sHTE-PEuySs8OjkDll4jkiYjaDE=.3d9568b0-404f-46ef-a483-ffdf14ff89ae@github.com>

On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? 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 feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - macOS: dynamically adapt toolbar style to headerbar height
>  - fix header bar height flicker
>  - NPE
>  - fix peer access outside of synchronizer
>  - improve title text documentation
>  - macOS: hide window title
>  - better documentation
>  - set minHeight to native height of title bar
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

![image](https://github.com/user-attachments/assets/464e1238-a394-42cb-947e-fe69d3bab83e)

I think it's fine, but is the window controls overlay supposed to take the whole window? I've set the background color just to demonstrate, it has no practical utility.

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

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

From tsayao at openjdk.org  Mon Nov  4 13:47:43 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 4 Nov 2024 13:47:43 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
Message-ID: <l7SDoEv5WFTAGckTLnmjUseeOFQR4WcBPk26pkxsumc=.abf7b999-3883-40d8-b759-8d6efccbd210@github.com>

On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? 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 feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - macOS: dynamically adapt toolbar style to headerbar height
>  - fix header bar height flicker
>  - NPE
>  - fix peer access outside of synchronizer
>  - improve title text documentation
>  - macOS: hide window title
>  - better documentation
>  - set minHeight to native height of title bar
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

I'm not sure if it's feasible, but having a `GtkOverlay` seems to work on a basic app paintable C app:


#include <gtk/gtk.h>

static gboolean on_draw_event(GtkWidget *widget, cairo_t *cr) {
    cairo_set_source_rgb(cr, 1.0, 0.0, 0.0);
    cairo_paint(cr);

    return FALSE;
}

static void create_overlay(GtkWidget *window) {
    GtkWidget *overlay;
    GtkWidget *hb;

    overlay = gtk_overlay_new();
    gtk_container_add(GTK_CONTAINER(window), overlay);

    hb = gtk_header_bar_new();
    gtk_header_bar_set_show_close_button(GTK_HEADER_BAR(hb), TRUE);
    gtk_header_bar_set_has_subtitle(GTK_HEADER_BAR(hb), FALSE);
    gtk_header_bar_set_custom_title(GTK_HEADER_BAR(hb), NULL);
    gtk_overlay_add_overlay(GTK_OVERLAY(overlay), hb);

    gtk_widget_set_valign(hb, GTK_ALIGN_START);
    gtk_widget_set_halign(hb, GTK_ALIGN_END);
}

int main(int argc, char *argv[]) {
    GtkWidget *window;

    // Initialize GTK
    gtk_init(&argc, &argv);

    GtkCssProvider *css_provider = gtk_css_provider_new();
    gtk_css_provider_load_from_data(css_provider,
        "headerbar {"
        "  background-color: rgba(255, 255, 255, 0.0);"
        "}",
        -1, NULL);

    gtk_style_context_add_provider_for_screen(gdk_screen_get_default(),
                                              GTK_STYLE_PROVIDER(css_provider),
                                              GTK_STYLE_PROVIDER_PRIORITY_USER);

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Test");
    gtk_window_set_decorated(GTK_WINDOW(window), FALSE);
    gtk_window_set_default_size(GTK_WINDOW(window), 400, 300);

    gtk_widget_set_app_paintable(window, TRUE);

    g_signal_connect(G_OBJECT(window), "draw", G_CALLBACK(on_draw_event), NULL);
    g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);
    create_overlay(window);
    gtk_widget_show_all(window);


    gtk_main();

    return 0;
}


Gtk4 even has [WindowControls](https://docs.gtk.org/gtk4/class.WindowControls.html). 

I started to play with the CSS to make it transparent, but it does not seem much straightforward, but possible.

Running the program with `GTK_DEBUG=interactive` makes it easier.

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

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

From aghaisas at openjdk.org  Mon Nov  4 14:24:41 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 4 Nov 2024 14:24:41 GMT
Subject: RFR: 8342911: Remove calls to doPrivileged in controls [v3]
In-Reply-To: <sMitwKVlTk_5VaeD93WXnP-wK9sEnwZYyzdArG5VTHY=.356f6a1c-51de-473e-9fec-74b8839fa307@github.com>
References: <fahJxT0pelJqcaMh_bIios9JVLEgwpvTeG1CV71GTcQ=.a2255c7a-1269-454a-adb9-23ce15ab1f0e@github.com>
 <sMitwKVlTk_5VaeD93WXnP-wK9sEnwZYyzdArG5VTHY=.356f6a1c-51de-473e-9fec-74b8839fa307@github.com>
Message-ID: <GT_YsIctAhP7B4tWWD8Km5M-ezV-DS6la_tfaJEA0yk=.e12b2440-c7e7-4fae-a9ed-e9283e89f3dd@github.com>

On Fri, 1 Nov 2024 17:45:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes doPrivileged in the following module:
>> 
>> - javafx.controls
>> 
>> See JDK-8342441 for details.
>> 
>> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.
>
> 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 8342911.do.priviliged.controls
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342911.do.priviliged.controls
>  - 8342911: Remove calls to doPrivileged in controls

Looks good to me.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1615#pullrequestreview-2413205588

From angorya at openjdk.org  Mon Nov  4 15:29:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 15:29:35 GMT
Subject: RFR: 8342914: Remove calls to doPrivileged in swt [v2]
In-Reply-To: <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com>
References: <lGGXH90dIw6klCyWnoxXnPjbVu7MkjtWC60SZQZp7Ww=.e0d67a5e-8162-4815-b4f4-9278e477b5bc@github.com>
 <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com>
Message-ID: <HCLN5uKorBSHxkt-gFyq98W0jBbmCf8y9n50COfclYk=.17009375-58da-41cb-abb9-a7ed35596bc6@github.com>

On Wed, 30 Oct 2024 18:16:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes doPrivileged in the following module:
>> 
>> - javafx.swt
>> 
>> See JDK-8342441 for details.
>> 
>> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.
>
> 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:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342914.do.privileged.swt
>  - Merge remote-tracking branch 'origin/master' into 8342914.do.privileged.swt
>  - 8342914: Remove calls to doPrivileged in swt

@aghaisas do you think you can review this please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1611#issuecomment-2455011914

From angorya at openjdk.org  Mon Nov  4 17:21:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 17:21:57 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v5]
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com>

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

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

 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - in case of hitting min max
 - Merge branch 'master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - ... and 28 more: https://git.openjdk.org/jfx/compare/5bf02be0...7c947083

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

Changes: https://git.openjdk.org/jfx/pull/1156/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=04
  Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod
  Patch: https://git.openjdk.org/jfx/pull/1156.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156

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

From angorya at openjdk.org  Mon Nov  4 15:17:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 15:17:37 GMT
Subject: Integrated: 8342911: Remove calls to doPrivileged in controls
In-Reply-To: <fahJxT0pelJqcaMh_bIios9JVLEgwpvTeG1CV71GTcQ=.a2255c7a-1269-454a-adb9-23ce15ab1f0e@github.com>
References: <fahJxT0pelJqcaMh_bIios9JVLEgwpvTeG1CV71GTcQ=.a2255c7a-1269-454a-adb9-23ce15ab1f0e@github.com>
Message-ID: <iWQZg9dM51bPfNp8FOFEBkdwz0mOnNcRFKAZG2-764U=.4bdc8681-3f66-4727-b51f-cd7e67835368@github.com>

On Mon, 28 Oct 2024 15:01:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removes doPrivileged in the following module:
> 
> - javafx.controls
> 
> See JDK-8342441 for details.
> 
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.

This pull request has now been integrated.

Changeset: 927f07bf
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/927f07bf9ad24a1dc40535bc426ff752e8e10a76
Stats:     77 lines in 6 files changed: 0 ins; 39 del; 38 mod

8342911: Remove calls to doPrivileged in controls

Reviewed-by: kcr, aghaisas

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

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

From angorya at openjdk.org  Mon Nov  4 15:21:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 15:21:34 GMT
Subject: Integrated: 8342457: Remove calls to doPrivileged in swing
In-Reply-To: <DYLhrFEtLin2F5YO_PVBJgpj5Pu40SsirpE2yBfWivU=.7e439fcd-941a-451a-a7b9-62ef244f63af@github.com>
References: <DYLhrFEtLin2F5YO_PVBJgpj5Pu40SsirpE2yBfWivU=.7e439fcd-941a-451a-a7b9-62ef244f63af@github.com>
Message-ID: <G0p9MdYz8iWIpxNfvnHyolwBv21TUzCHJRGtpJSRDR4=.7d91e688-dbbe-4688-a6af-c6eed4c52130@github.com>

On Mon, 28 Oct 2024 14:59:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removes doPrivileged in the following module:
> 
> - javafx.swing
> 
> See JDK-8342441 for details.
> 
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.

This pull request has now been integrated.

Changeset: 6d690848
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6d690848c9461e434a39c387be283af9e75ddc30
Stats:     109 lines in 5 files changed: 4 ins; 78 del; 27 mod

8342457: Remove calls to doPrivileged in swing

Reviewed-by: kcr, psadhukhan

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

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

From angorya at openjdk.org  Mon Nov  4 15:24:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 15:24:34 GMT
Subject: Integrated: 8342627: Create Eclipse project files for jdk.jsobject
In-Reply-To: <pzrxt2ohs0MJHbvjp783G-wcKOPAKKEZHrKTPBGNk3I=.f2bfecfd-cc48-4942-bf6b-8c35ae3cf45b@github.com>
References: <pzrxt2ohs0MJHbvjp783G-wcKOPAKKEZHrKTPBGNk3I=.f2bfecfd-cc48-4942-bf6b-8c35ae3cf45b@github.com>
Message-ID: <t5_3hqInrcYIGpGG66dVCjc1iBrPVfhNLh8SVjhBzu0=.83a5cbf3-85af-42f7-88bb-ae6fbb8e1205@github.com>

On Thu, 31 Oct 2024 22:55:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added eclipse project files.
> 
> The project is named `jsobject` instead of jdk.jsobject, similarly to how the other projects are named "base", "controls", ... instead of their full module names.

This pull request has now been integrated.

Changeset: 5bf02be0
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5bf02be0e517aa953c71db0c35468b419026bff8
Stats:     16 lines in 3 files changed: 15 ins; 0 del; 1 mod

8342627: Create Eclipse project files for jdk.jsobject

Reviewed-by: jhendrikx

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

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

From kcr at openjdk.org  Mon Nov  4 18:00:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 4 Nov 2024 18:00:53 GMT
Subject: RFR: 8342917: GHA: Intermittent build failure on Linux while
 downloading ant
Message-ID: <Rm4H39dOLBOYV-OmhnBU1hcOsPmxVIkaWPhIjcNT8zM=.32610c67-d7c0-47b3-a456-cde2d70c66ad@github.com>

We are getting frequent intermittent failures downloading `ant` on Linux. The fix is to use the package manager to install ant rather than downloading it from `apache.org`.

This only impacts GHA test builds, so the only verification needed for this fix is that the GHA build passes on all platforms.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into 8342917-gha-linux-ant
 - Missed updating PATH in one place
 - 8342917: GHA: Intermittent build failure on Linux while downloading ant

Changes: https://git.openjdk.org/jfx/pull/1623/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342917
  Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1623.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1623/head:pull/1623

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

From jvos at openjdk.org  Mon Nov  4 18:55:22 2024
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 4 Nov 2024 18:55:22 GMT
Subject: RFR: 8342917: GHA: Intermittent build failure on Linux while
 downloading ant
In-Reply-To: <Rm4H39dOLBOYV-OmhnBU1hcOsPmxVIkaWPhIjcNT8zM=.32610c67-d7c0-47b3-a456-cde2d70c66ad@github.com>
References: <Rm4H39dOLBOYV-OmhnBU1hcOsPmxVIkaWPhIjcNT8zM=.32610c67-d7c0-47b3-a456-cde2d70c66ad@github.com>
Message-ID: <70LIeGfKAFR4BM2aEiHcKa1hQCWjuinbr5Tde5zrXI0=.9645ec62-d3a6-4fcc-be74-c2af92f5e675@github.com>

On Mon, 4 Nov 2024 17:42:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We are getting frequent intermittent failures downloading `ant` on Linux. The fix is to use the package manager to install ant rather than downloading it from `apache.org`.
> 
> This only impacts GHA test builds, so the only verification needed for this fix is that the GHA build passes on all platforms.

Makes sense.

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1623#pullrequestreview-2413843315

From angorya at openjdk.org  Mon Nov  4 20:12:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 20:12:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
Message-ID: <Zp2xO_KuLLqaHrCCRaRHwBLU7WwLrWvXZiRybAoE4w4=.49eafb15-417c-46e2-82d7-8019c6cc9349@github.com>

On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? 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 feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - macOS: dynamically adapt toolbar style to headerbar height
>  - fix header bar height flicker
>  - NPE
>  - fix peer access outside of synchronizer
>  - improve title text documentation
>  - macOS: hide window title
>  - better documentation
>  - set minHeight to native height of title bar
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

Moving from one monitor to another with a different scale works as expected.

Opening the EXTENDED Stage with `Scene.setNodeOrientation(RTL)` produces expected result in terms of the native decorations:

![Screenshot 2024-11-04 120500](https://github.com/user-attachments/assets/680aea39-63e6-4c30-b109-e5227d4aa08c)

[Unrelated] Curiously, setting `Scene.setNodeOrientation(RTL)` on an already open window (DECORATED) does not change the native decorations.  I am not sure if this is a bug or works as expected, but in any case I don't care - seems to be a rather unlikely scenario.

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

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

From angorya at openjdk.org  Mon Nov  4 20:15:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 4 Nov 2024 20:15:38 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
Message-ID: <JeC3w7NYd5TGN8eCJoToiKvB08DsrQ-X_ZYzB0EgM6A=.d726ae8c-0cab-420e-925d-adc20810eac5@github.com>

On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? 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 feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - macOS: dynamically adapt toolbar style to headerbar height
>  - fix header bar height flicker
>  - NPE
>  - fix peer access outside of synchronizer
>  - improve title text documentation
>  - macOS: hide window title
>  - better documentation
>  - set minHeight to native height of title bar
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

There is, however, one problem in RTL mode on Win11:
something is wrong with the hover area of the native close ([x]) button.  If I click on the center of the X, nothing happens, and it does not show the hover status.  If I move the mouse pointer closer to the edge of the [x] button, the hover decoration comes on and the window can be closed.

Can you check please?

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

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

From kevin.rushforth at oracle.com  Mon Nov  4 23:07:38 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 4 Nov 2024 15:07:38 -0800
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <9a4fbe92-b831-421c-a1ef-c15322716b8f@gmail.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
 <9a4fbe92-b831-421c-a1ef-c15322716b8f@gmail.com>
Message-ID: <7c2b113d-9641-4d80-a987-d8335251e5b6@oracle.com>

The goal of incubating these or any other APIs is to get feedback from 
applications developers as they use them, and be able to react to that 
feedback with the freedom of being able to make incompatible changes. If 
and when a feature is generally accepted, and we think the API is ready, 
we would then propose finalizing it.

I'll reply to the questions raised about?RichTextArea and InputMap 
separately, with a new subject line, to decouple it from the discussion 
of incubator modules in general.

-- Kevin


On 11/3/2024 7:46 AM, John Hendrikx wrote:
> I can only second this.? I haven't looked at the RichTextArea, but 
> find it extremely odd to hear that it also includes part of the input 
> map proposal instead of just a new Control/Skin/Behavior.? Any changes 
> to how input maps work should be a separate proposal and PR.
>
> --John
>
> On 02/11/2024 00:19, Michael Strau? wrote:
>> I think it should be made clear that incubation is not an alternative
>> to, or a path around community concensus. Specifically, I'm looking at
>> the RichTextArea proposal, which seems to also incubate the InputMap
>> proposal. If we accepted the incubation of incidental features without
>> community concensus, then surely at some point in the future, we'd be
>> discussing that we now must commit to a controversial incidental
>> feature because the momentum is too strong, or because we'd be
>> breaking code of too many users that are already using the new
>> features. Any discussion around promoting the main incubating feature
>> to API, and dropping incidental features will be tainted with
>> real-world usage arguments.


From kevin.rushforth at oracle.com  Mon Nov  4 23:07:40 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 4 Nov 2024 15:07:40 -0800
Subject: RichTextArea and InputMap incubator modules [was: Proposal: JavaFX
 Incubator Modules]
In-Reply-To: <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
Message-ID: <316c9c47-0450-4424-bd6b-9466232e6a57@oracle.com>

As noted, the current RichTextArea proposal depends on the InputMap 
proposal. Andy will make this more clear by filing a new JBS Enhancement 
(or reusing the existing one) for "InputMap (Incubator)", and adding 
that issue to the RichTextArea PR.

The idea of incubating InputMap along with RichTextArea is to get 
feedback on InputMap as an incubating feature with a concrete example 
control that uses it, and would benefit by it. An alternative would have 
been to incubate InputMap separately, although that would require 
picking a simple control or two and creating a "test" version of that 
control solely for the purpose of testing InputMap. I don't think it 
would provide the kind of feedback we are looking for. Using it with a 
control that we actually expect developers to use seems like a better 
test of InputMap. It does tie the two proposals together, at least 
during the time that they are incubating.

Given that RTA and InputMap are two distinct features, I can see three 
likely outcomes after incubating for some number of releases, where we 
gain feedback and iterate the design and API:

1. Both RTA and InputMap gain general acceptance among app developers -- 
in this case, both would be finalized at the same time in some future 
release. This is what we are aiming for.
2. RTA gains general acceptance, but InputMap does not -- in this case, 
RTA would need to be reworked to remove all dependencies on InputMap, 
with some alternate customization of behavior that is specific to RTA, 
which would then be finalized in some future release.
3. Neither RTA nor InputMap gain general acceptance -- in this case, 
both would be removed in some future release.

-- Kevin


On 11/1/2024 4:19 PM, Michael Strau? wrote:
> I think it should be made clear that incubation is not an alternative
> to, or a path around community concensus. Specifically, I'm looking at
> the RichTextArea proposal, which seems to also incubate the InputMap
> proposal. If we accepted the incubation of incidental features without
> community concensus, then surely at some point in the future, we'd be
> discussing that we now must commit to a controversial incidental
> feature because the momentum is too strong, or because we'd be
> breaking code of too many users that are already using the new
> features. Any discussion around promoting the main incubating feature
> to API, and dropping incidental features will be tainted with
> real-world usage arguments.


From angorya at openjdk.org  Tue Nov  5 00:22:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 00:22:43 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
Message-ID: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>

On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? 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 feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - macOS: dynamically adapt toolbar style to headerbar height
>  - fix header bar height flicker
>  - NPE
>  - fix peer access outside of synchronizer
>  - improve title text documentation
>  - macOS: hide window title
>  - better documentation
>  - set minHeight to native height of title bar
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d

first batch of comments up until and including HeaderBar.
to be continued...

buildSrc/win.gradle line 329:

> 327:         "winmm.lib", "imm32.lib", "shell32.lib", "Uiautomationcore.lib", "dwmapi.lib", "uxtheme.lib",
> 328:         "/DELAYLOAD:user32.dll", "/DELAYLOAD:urlmon.dll", "/DELAYLOAD:winmm.dll", "/DELAYLOAD:shell32.dll",
> 329:         "/DELAYLOAD:Uiautomationcore.dll", "/DELAYLOAD:dwmapi.dll", "/DELAYLOAD:uxtheme.dll"]).flatten()

minor suggestion: placing each entry on separate line might simplify maintenance and reduce merge conflicts.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 170:

> 168:      * Indicates that the window is modal which affects whether the window is minimizable.
> 169:      */
> 170:     @Native public static final int MODAL = 1 << 10;

minor: would it be better to add EXTENDED after the MODAL to minimize the change?  Do the actual values matter?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 267:

> 265:         if ((styleMask & UNIFIED) != 0 && (styleMask & EXTENDED) != 0) {
> 266:             throw new RuntimeException("UNIFIED and EXTENDED cannot be combined");
> 267:         }

is it even possible to create a window with both `UNIFIED` and `EXTENDED` set?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 74:

> 72:  *         <li>{@link Region} ? {@code window-button}, {@code maximize-button}
> 73:  *         <li>{@link Region} ? {@code window-button}, {@code close-button}
> 74:  *     </ul>

1. I think this part (css ref) is rather important and maybe should be a part of this PR.  It would be nice to be able to review the CSS reference as a part of this PR.
2. if you don't kind, could you please link your JEP to the PR and the ticket?
3. could you please include the "application title" row in the table in the JEP?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 78:

> 76:  *
> 77:  * <table style="white-space: nowrap">
> 78:  *     <caption>CSS properties of {@code window-button-container}</caption>

The new CSS properties need to be included in `cssref.html`, along with the description of platform availability.

Should this be done as part of this PR?  (that would be my preference)

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 104:

> 102:  *     </thead>
> 103:  *     <tbody><tr>
> 104:  *         <th>-fx-button-order</th><td>&lt;integer&gt;</td><td>0/1/2</td>

what happens when CSS sets all buttons to the same value?
should this be something that user has control over vs. defined by the platform?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 199:

> 197:      */
> 198:     private final StyleableBooleanProperty allowRtl =
> 199:         new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) {

why is `allowRtl` a property and not a simple flag?
why is it allowed to be changed via CSS via `-fx-allow-rtl`?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 273:

> 271:     public ButtonType buttonAt(double x, double y) {
> 272:         for (var button : orderedButtons) {
> 273:             if (button.isVisible() && button.getBoundsInParent().contains(x, y)) {

are we using the right coordinates?  x,y seems to be in the "window" coordinates, while button.parent is... not.  Shouldn't you do a proper conversion here?

(also notice my earlier comment about the Close button in RTL mode)

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 286:

> 284:      * @param type the event type
> 285:      * @param button the button type
> 286:      * @param x the X coordinate, in pixels relative to the window

this is an internal class, but is it correct to refer to the "window coordinates"?  what are these?  platform window coordinates?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 339:

> 337: 
> 338:     private void handleMouseUp(Node node, ButtonType buttonType) {
> 339:         boolean releasedOnButton = buttonAtMouseDown == node;

very minor stylistic suggestion:

boolean releasedOnButton = (buttonAtMouseDown == node);

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 354:

> 352:                 case MINIMIZE -> stage.setIconified(true);
> 353:                 case MAXIMIZE -> stage.setMaximized(!stage.isMaximized());
> 354:                 case CLOSE -> stage.close();

should this `switch` have a default case?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 360:

> 358: 
> 359:     private void onFocusedChanged(boolean focused) {
> 360:         for (var node : new Node[] {minimizeButton, maximizeButton, closeButton}) {

how is this better than 

minimizeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);
maximizeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);
closeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);

?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 414:

> 412: 
> 413:         double width = getWidth();
> 414:         double button1Width = boundedWidth(button1);

Q: do we want to snap to pixel every time we use Node.[min/pref/max] values to avoid jitter and fuzzy edges?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 490:

> 488: 
> 489:         private static final List<CssMetaData<?, ?>> METADATA =
> 490:             Stream.concat(getClassCssMetaData().stream(), Stream.of(BUTTON_ORDER_METADATA)).toList();

[unrelated] this malloc galore deserves a utility method

https://bugs.openjdk.org/browse/JDK-8320796

modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 278:

> 276:         }
> 277: 
> 278:         View.EventHandler eventHandler = view.getEventHandler();

should this check be moved before L271?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinView.java line 115:

> 113: 
> 114:             EventHandler eventHandler = getEventHandler();
> 115:             if (eventHandler != null && eventHandler.pickDragAreaNode(wx, wy) != null) {

computing `wx, wy` may not be necessary if `eventHandler != null` check is moved before L111

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 385:

> 383:      * Classifies the window region at the specified physical coordinate.
> 384:      * <p>
> 385:      * This method is called from native code.

is it called from the fx application thread?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 390:

> 388:      * @param y the Y coordinate in physical pixels
> 389:      */
> 390:     @SuppressWarnings("unused")

tangentially related conversation starter:

should we have a couple of annotations for code called from JNI/native and reflection?

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java line 206:

> 204:     @Override public String toString() {
> 205:         View view = getPlatformView();
> 206:         return (" scene: " + hashCode() + " @ (" + view.getWidth() + "," + view.getHeight() + ")");

leading space in `toString()` might be a _bad idea_

suggestion (JSON-like):

`return "ViewScene" + hashCode() + "{width=" + view.getWidth() + ", height=" + view.getHeight() + "}";`

modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java line 156:

> 154:      * Indicates that a system supports {@link javafx.stage.StageStyle#EXTENDED}.
> 155:      * <p>
> 156:      * This feature is currently supported on Windows, Linux, and macOS.

would it make sense to add more information similarly to UNIFIED_WINDOW on L151?
maybe pointing to different levels of support?

I don't know whether it makes sense to bring the whole table from the JEP here, but maybe somewhere (HeaderBar)?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 53:

> 51:  * account for the default window buttons (minimize, maximize, close). If a child is configured to be
> 52:  * centered in the {@code center} area, it is laid out with respect to the stage, and not with respect
> 53:  * to the {@code center} area. This ensures that the child will appear centered in the stage regardless

should there be more fine tuned control for growing/shrinking?

can the application just add a single container like GridPane that handles the resizing?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 59:

> 57:  * {@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children. If the child's
> 58:  * resizable range prevents it from be resized to fit within its position, it will be vertically centered
> 59:  * relative to the available space; this alignment can be customized with a layout constraint.

what if the components are too large to fit, will clipping occur?  should this behavior be mentioned?

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

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2414057652
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828345233
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828349822
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828354349
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828510506
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828377118
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828502773
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828528087
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828531686
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828533592
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828534701
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828535399
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828536256
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828538043
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828543247
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828545452
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828548458
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828549557
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828550177
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828553092
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828555928
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828560450
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828558349

From angorya at openjdk.org  Tue Nov  5 00:22:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 00:22:43 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <YuUsyV8PYaBQfbksDFjtNjDdjftc7OrcHdazT7NlbOk=.1c58876c-902f-4f00-bd87-6893b3f3d8de@github.com>

On Mon, 4 Nov 2024 23:54:52 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 385:
> 
>> 383:      * Classifies the window region at the specified physical coordinate.
>> 384:      * <p>
>> 385:      * This method is called from native code.
> 
> is it called from the fx application thread?

would it be possible to specify where from?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828551255

From mstrauss at openjdk.org  Tue Nov  5 00:57:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 00:57:16 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v20]
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: <IjsgI_zAlP3GwvbupthNG5upI6hpT35ksOouCeUQWlY=.3b0e96c7-2167-4478-a704-272d05beb9e8@github.com>

> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
> 
> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
> 
> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
> 
> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
> 
> This is how it looks like on each of the three operating systems:
> 
> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
> 
> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
> 
> ## Usage
> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
> 
> public class MyApp extends Application {
>     @Override
>     public void start(Stage stage) {
>         var headerBar = new HeaderBar();
>         headerBar.setCenter(new TextField());
> 
>         var root = new BorderPane();
>         root.setTop(headerBar);
> 
>         stage.setScene(new Scene(root));
>         stage.initStyle(StageStyle.EXTENDED);
>         stage.show();
>     }
> }
> 
> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
> 
> ## Platform integration
> The implementation varies per platform, and ranges from pretty easy to quite involved:
> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSWindowStyleMaskFullSizeContentView` flag. A click-and-drag operation is ini...

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

  fix mirroring/unmirroring of X coord in win-glass

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/9b63892d..e7febc54

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

  Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 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  Tue Nov  5 01:05:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:05:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <JeC3w7NYd5TGN8eCJoToiKvB08DsrQ-X_ZYzB0EgM6A=.d726ae8c-0cab-420e-925d-adc20810eac5@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <JeC3w7NYd5TGN8eCJoToiKvB08DsrQ-X_ZYzB0EgM6A=.d726ae8c-0cab-420e-925d-adc20810eac5@github.com>
Message-ID: <caJRzAW-DALwgwAh0zTTZW8Fc0BgCbwVV4bqVkAh-PM=.09b56c26-f9bb-4231-93a1-1f6ebedc63de@github.com>

On Mon, 4 Nov 2024 20:13:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> There is, however, one problem in RTL mode on Win11: something is wrong with the hover area of the native close ([x]) button. If I click on the center of the X, nothing happens, and it does not show the hover status. If I move the mouse pointer closer to the edge of the [x] button, the hover decoration comes on and the window can be closed.
> 
> Can you check please?

Thanks for discovering this, there was a problem with mirrored coordinates in RTL windows. Should be fixed now.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 170:
> 
>> 168:      * Indicates that the window is modal which affects whether the window is minimizable.
>> 169:      */
>> 170:     @Native public static final int MODAL = 1 << 10;
> 
> minor: would it be better to add EXTENDED after the MODAL to minimize the change?  Do the actual values matter?

The values don't matter, as they are referred to with their constant name in native code. We could minimize the diff here, but then the "visual kind" flags wouldn't be grouped together...

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 267:
> 
>> 265:         if ((styleMask & UNIFIED) != 0 && (styleMask & EXTENDED) != 0) {
>> 266:             throw new RuntimeException("UNIFIED and EXTENDED cannot be combined");
>> 267:         }
> 
> is it even possible to create a window with both `UNIFIED` and `EXTENDED` set?

No, this is just a sanity check.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2456006455
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828589537
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828589780

From mstrauss at openjdk.org  Tue Nov  5 01:08:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:08:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <WkrsybmHI5uQaZmarE6YagSzAl19r9tdDOMkawG_Zrs=.f4469fda-5c2e-4e4c-9106-bcd552451d18@github.com>

On Mon, 4 Nov 2024 20:55:41 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 78:
> 
>> 76:  *
>> 77:  * <table style="white-space: nowrap">
>> 78:  *     <caption>CSS properties of {@code window-button-container}</caption>
> 
> The new CSS properties need to be included in `cssref.html`, along with the description of platform availability.
> 
> Should this be done as part of this PR?  (that would be my preference)

`WindowControlsOverlay` is not API, it's an implementation detail and as such must not be documented in `cssref.html`. This is by design: currently, this feature has a minimal API with just three new API elements: `StageStyle.EXTENDED`, `HeaderBar`, and `HeaderBarBase`. If we allowed app developers to customize window buttons, the API would explode in size and the specification burden would be immense. Let's not go there.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828591915

From mstrauss at openjdk.org  Tue Nov  5 01:13:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:13:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <mbqF2lVG2ly9I7bwQG8jXGH_1HqlYRgA2t2DwPR1Olg=.873ea217-2cdf-4af0-9c6a-74a566587dc4@github.com>

On Mon, 4 Nov 2024 22:54: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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 104:
> 
>> 102:  *     </thead>
>> 103:  *     <tbody><tr>
>> 104:  *         <th>-fx-button-order</th><td>&lt;integer&gt;</td><td>0/1/2</td>
> 
> what happens when CSS sets all buttons to the same value?
> should this be something that user has control over vs. defined by the platform?

The buttons are sorted with `List.sort`, so that will dictate what happens in this scenario. Note that this class is not API, and neither users nor the platform will have any control over it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828595321

From mstrauss at openjdk.org  Tue Nov  5 01:22:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:22:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <WlzbSwKVGAX-YSZ0gXAndpcDeNSguDwnLr5BqtjyAGQ=.8818e934-0f56-4d7e-b8fb-9aae6d832ecc@github.com>

On Mon, 4 Nov 2024 23:21:22 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 199:
> 
>> 197:      */
>> 198:     private final StyleableBooleanProperty allowRtl =
>> 199:         new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) {
> 
> why is `allowRtl` a property and not a simple flag?
> why is it allowed to be changed via CSS via `-fx-allow-rtl`?

The purpose is to allow JavaFX developers (that is us, not users of JavaFX) to define the entire appearance of `WindowControlsOverlay` with a CSS file. This should make it easier to maintain it, since we won't have to keep looking in two places to change the appearance.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 273:
> 
>> 271:     public ButtonType buttonAt(double x, double y) {
>> 272:         for (var button : orderedButtons) {
>> 273:             if (button.isVisible() && button.getBoundsInParent().contains(x, y)) {
> 
> are we using the right coordinates?  x,y seems to be in the "window" coordinates, while button.parent is... not.  Shouldn't you do a proper conversion here?
> 
> (also notice my earlier comment about the Close button in RTL mode)

`WindowControlsOverlay` is not part of the JavaFX scene graph. It is a resizeable _overlay_ control that always stretches the entire window, and with that in mind, `button.getBoundsInParent()` will translate the button bounds to window coordinates.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 286:
> 
>> 284:      * @param type the event type
>> 285:      * @param button the button type
>> 286:      * @param x the X coordinate, in pixels relative to the window
> 
> this is an internal class, but is it correct to refer to the "window coordinates"?  what are these?  platform window coordinates?

JavaFX window coordinates, i.e. scaled coordinates. For coordinates coming from the native toolkit, I have used the term "physical pixels". Physical pixels are always converted at the Java-native boundary, and are not used in JavaFX internals.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 354:
> 
>> 352:                 case MINIMIZE -> stage.setIconified(true);
>> 353:                 case MAXIMIZE -> stage.setMaximized(!stage.isMaximized());
>> 354:                 case CLOSE -> stage.close();
> 
> should this `switch` have a default case?

No, because we never have more than three window buttons. If we ever had, we would want to change the code instead of running into a default clause.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828597391
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828600111
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828601573
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828602372

From mstrauss at openjdk.org  Tue Nov  5 01:26:35 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:26:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <YuUsyV8PYaBQfbksDFjtNjDdjftc7OrcHdazT7NlbOk=.1c58876c-902f-4f00-bd87-6893b3f3d8de@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <YuUsyV8PYaBQfbksDFjtNjDdjftc7OrcHdazT7NlbOk=.1c58876c-902f-4f00-bd87-6893b3f3d8de@github.com>
Message-ID: <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com>

On Mon, 4 Nov 2024 23:57:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 385:
>> 
>>> 383:      * Classifies the window region at the specified physical coordinate.
>>> 384:      * <p>
>>> 385:      * This method is called from native code.
>> 
>> is it called from the fx application thread?
>
> would it be possible to specify where from?

Yes, but if we do that, then we should do it everywhere it matters. The native toolkits are not multi-threaded, so all native upcalls happen on the JavaFX application thread. We should probably do this in another PR, and discuss how to do it uniformly (javadoc, annotation, etc).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828604346

From mstrauss at openjdk.org  Tue Nov  5 01:26:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:26:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <jFcEudWszzvw2o7XBbfuzoHAzj-KLHQ-K57FSJTF66g=.7b68a8c1-fb87-46bf-8593-ed84b4223960@github.com>

On Mon, 4 Nov 2024 23:56:00 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 390:
> 
>> 388:      * @param y the Y coordinate in physical pixels
>> 389:      */
>> 390:     @SuppressWarnings("unused")
> 
> tangentially related conversation starter:
> 
> should we have a couple of annotations for code called from JNI/native and reflection?

That may be a good idea, see my other comment.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828604481

From mstrauss at openjdk.org  Tue Nov  5 01:32:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:32:16 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
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: <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>

> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
> 
> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
> 
> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
> 
> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
> 
> This is how it looks like on each of the three operating systems:
> 
> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
> 
> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
> 
> ## Usage
> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
> 
> public class MyApp extends Application {
>     @Override
>     public void start(Stage stage) {
>         var headerBar = new HeaderBar();
>         headerBar.setCenter(new TextField());
> 
>         var root = new BorderPane();
>         root.setTop(headerBar);
> 
>         stage.setScene(new Scene(root));
>         stage.initStyle(StageStyle.EXTENDED);
>         stage.show();
>     }
> }
> 
> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
> 
> ## Platform integration
> The implementation varies per platform, and ranges from pretty easy to quite involved:
> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSWindowStyleMaskFullSizeContentView` flag. A click-and-drag operation is ini...

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

  stylistic changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/e7febc54..d1c388bf

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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  Tue Nov  5 01:32:17 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:32:17 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <zIzYk7G_TQ0fhOREYgiKm5XdLiZp8buO4Jbgydh7-z8=.9940e232-9c5b-4346-9bbd-bf443081488b@github.com>

On Mon, 4 Nov 2024 23:33:34 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 360:
> 
>> 358: 
>> 359:     private void onFocusedChanged(boolean focused) {
>> 360:         for (var node : new Node[] {minimizeButton, maximizeButton, closeButton}) {
> 
> how is this better than 
> 
> minimizeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);
> maximizeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);
> closeButton.pseudoClassStateChanged(ACTIVE_PSEUDOCLASS, focused);
> 
> ?

I don't really care one way or the other, so I changed it to your suggestion.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828607779

From mstrauss at openjdk.org  Tue Nov  5 01:37:40 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:37:40 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <yhTB2Rk5373sOC31sHTE-PEuySs8OjkDll4jkiYjaDE=.3d9568b0-404f-46ef-a483-ffdf14ff89ae@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <yhTB2Rk5373sOC31sHTE-PEuySs8OjkDll4jkiYjaDE=.3d9568b0-404f-46ef-a483-ffdf14ff89ae@github.com>
Message-ID: <DyjcLesesixYmjhOUj5bQDNibtRyIL0B5UCIMJlK-T4=.13a09f3c-3a91-49ec-a30b-76c78148fdd5@github.com>

On Mon, 4 Nov 2024 11:28:35 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> I think it's fine, but is the window controls overlay supposed to take the whole window? I've set the background color just to demonstrate, it has no practical utility.

Yes, the overlay is resizable and will always stretch the entire window. As you point out, there's no practical significance, as overlays are not part of the scene graph and applications will never be able to interact with them.

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

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

From mstrauss at openjdk.org  Tue Nov  5 01:43:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 01:43:42 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
Message-ID: <Tk4e_cE4kedixu2kGpxOrZtc_ynJSqZwQfsoWanTsi0=.f1940035-f2ae-4fd8-89b2-9637da8d1833@github.com>

On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stylistic changes

> I'm not sure if it's feasible, but having a `GtkOverlay` seems to work on a basic app paintable C app:
>
> Gtk4 even has [WindowControls](https://docs.gtk.org/gtk4/class.WindowControls.html).
> 
> I started to play with the CSS to make it transparent, but it does not seem much straightforward, but possible.
> 
> Running the program with `GTK_DEBUG=interactive` makes it easier.

The main problem with this approach is that it presupposes that the drawing is only done in GTK callbacks. But that's not how JavaFX interacts with GTK, so I think it will probably not work. I haven't found a way to simultaneously use the current JavaFX rendering approach and mix in GTK widgets on the same surface.

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

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

From mstrauss at openjdk.org  Tue Nov  5 05:52:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 05:52:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <5J6FkOVa9BEie7CUhiEqFlH4Bv-i_7fdQZQ0mhg3XHk=.de82e99c-42b3-4fb7-a145-50d0540870d4@github.com>

On Tue, 5 Nov 2024 00:00:48 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java line 206:
> 
>> 204:     @Override public String toString() {
>> 205:         View view = getPlatformView();
>> 206:         return (" scene: " + hashCode() + " @ (" + view.getWidth() + "," + view.getHeight() + ")");
> 
> leading space in `toString()` might be a _bad idea_
> 
> suggestion (JSON-like):
> 
> `return "ViewScene" + hashCode() + "{width=" + view.getWidth() + ", height=" + view.getHeight() + "}";`

Yep, but this is existing code. The GitHub diff viewer makes it seem like it was changed, but it isn't.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828762290

From mstrauss at openjdk.org  Tue Nov  5 06:03:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 06:03:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>

On Tue, 5 Nov 2024 00:05:43 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java line 156:
> 
>> 154:      * Indicates that a system supports {@link javafx.stage.StageStyle#EXTENDED}.
>> 155:      * <p>
>> 156:      * This feature is currently supported on Windows, Linux, and macOS.
> 
> would it make sense to add more information similarly to UNIFIED_WINDOW on L151?
> maybe pointing to different levels of support?
> 
> I don't know whether it makes sense to bring the whole table from the JEP here, but maybe somewhere (HeaderBar)?

It links directly to `StageStyle.EXTENDED`, which contains lots of information. I don't think we need it here.

By the way, there are no support levels. The feature is supported in its entirety, as specified, on all desktop platforms. The table in the JEP is just informational to help OpenJFX developers understand what we're talking about. It's not a specification, and it can't be a specification because we either don't control things (for example, we have no influence on rounded corners, this could be changed with any future OS version) or because we'd be specifying us into a corner. There's no point prescribing every minute detail, and then being responsible to keep it working _exactly_ as described, even though the semantics are unchanged.

The relevant parts are specified in `StageStyle.EXTENDED` and `HeaderBar`, and I wouldn't go further than this. We don't specify the details of `StageStyle.DECORATED` for each OS; why should we do it for `StageStyle.EXTENDED`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828772282

From mstrauss at openjdk.org  Tue Nov  5 06:10:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 06:10:39 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <eCsUWGygS_-iYbacembeZX4dqY2jQ3KvGSknl8qPsVk=.74ad0349-61bf-42dc-aae8-2658471a12c9@github.com>

On Tue, 5 Nov 2024 00:09:59 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 59:
> 
>> 57:  * {@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children. If the child's
>> 58:  * resizable range prevents it from be resized to fit within its position, it will be vertically centered
>> 59:  * relative to the available space; this alignment can be customized with a layout constraint.
> 
> what if the components are too large to fit, will clipping occur?  should this behavior be mentioned?

The components can't be too large to fit:
`{@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children.`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828778020

From jdv at openjdk.org  Tue Nov  5 06:17:04 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 5 Nov 2024 06:17:04 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass
Message-ID: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>

This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).

Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().

I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

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

Commit messages:
 - Remove PrivilegedAction and AccessControl imports
 - Remove doPrivileged calls

Changes: https://git.openjdk.org/jfx/pull/1624/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342454
  Stats: 436 lines in 35 files changed: 17 ins; 250 del; 169 mod
  Patch: https://git.openjdk.org/jfx/pull/1624.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1624/head:pull/1624

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

From mstrauss at openjdk.org  Tue Nov  5 06:21:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 06:21:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <5NSldjtN-bXFCzyQWLFshN2UHgqe2yH2cxXswc2rLqc=.33b99dd0-c5c9-4bb5-aa54-c14c59091f71@github.com>

On Tue, 5 Nov 2024 00:13:20 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 53:
> 
>> 51:  * account for the default window buttons (minimize, maximize, close). If a child is configured to be
>> 52:  * centered in the {@code center} area, it is laid out with respect to the stage, and not with respect
>> 53:  * to the {@code center} area. This ensures that the child will appear centered in the stage regardless
> 
> should there be more fine tuned control for growing/shrinking?
> 
> can the application just add a single container like GridPane that handles the resizing?

What do you mean with growing and shrinking?

An application can add a single `GridPane` to `HeaderBar.center`, and set its prefWidth to `POSITIVE_INFINITY`. This will extend the `GridPane` across the entire width of the header bar (excluding the window button area).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1828786562

From jdv at openjdk.org  Tue Nov  5 06:37:36 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 5 Nov 2024 06:37:36 GMT
Subject: RFR: 8342914: Remove calls to doPrivileged in swt [v2]
In-Reply-To: <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com>
References: <lGGXH90dIw6klCyWnoxXnPjbVu7MkjtWC60SZQZp7Ww=.e0d67a5e-8162-4815-b4f4-9278e477b5bc@github.com>
 <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com>
Message-ID: <LPw74a74CRnlc3_5PEWXa3Q1RrjOkep5deKK6ZAbSws=.f36fced4-9d10-4ced-a6e2-c38c99c3291d@github.com>

On Wed, 30 Oct 2024 18:16:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes doPrivileged in the following module:
>> 
>> - javafx.swt
>> 
>> See JDK-8342441 for details.
>> 
>> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.
>
> 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:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342914.do.privileged.swt
>  - Merge remote-tracking branch 'origin/master' into 8342914.do.privileged.swt
>  - 8342914: Remove calls to doPrivileged in swt

Change looks good to me.

modules/javafx.swt/src/main/java/javafx/embed/swt/FXCanvas.java line 84:

> 82: import org.eclipse.swt.widgets.Listener;
> 83: import org.eclipse.swt.widgets.Shell;
> 84: import com.sun.glass.ui.Application;

We were planning to not re-order imports as part of this exercise as it just adds more information to the PR.

Since this PR has less files it is fine.

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

Marked as reviewed by jdv (Author).

PR Review: https://git.openjdk.org/jfx/pull/1611#pullrequestreview-2414733970
PR Review Comment: https://git.openjdk.org/jfx/pull/1611#discussion_r1828800524

From arapte at openjdk.org  Tue Nov  5 07:46:35 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Nov 2024 07:46:35 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v2]
In-Reply-To: <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>
Message-ID: <PhLOhoGkoqFJ-A9zEXPKxM9R1Vr61UfvqZBI6cv9pLI=.d5094175-cd47-48c9-b309-b458981de97c@github.com>

On Fri, 1 Nov 2024 15:01:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

LGTM, with one minor comment. Please take a look.

modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 1582:

> 1580:                         webEngine.debugger.messageCallback;
> 1581:                 if (messageCallback != null) {
> 1582:                     messageCallback.call(message);

@SuppressWarnings("removal") can be removed from this method.

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1620#pullrequestreview-2414747585
PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1828809646

From jcorvel at gmail.com  Tue Nov  5 10:40:18 2024
From: jcorvel at gmail.com (Johan Corveleyn)
Date: Tue, 5 Nov 2024 11:40:18 +0100
Subject: Integrated: 8340982: [win] Dead key followed by Space generates
 two characters instead of one
In-Reply-To: <CAB84uBVQGGY4SA1Nzs0ZHW7gcHPHJ1OX00YtVygz=EiaaOvVsw@mail.gmail.com>
References: <PyljFPympx4RWe_rxfGQt1cx8FDg-Vwp-vzIbprOe54=.2d8f387e-5b55-4b9c-92ae-5f4995a7aae3@github.com>
 <AJ-GDGQM5PpeJ3rJWwqnf5celujc0dBJcVxxn6tdApw=.360a16d5-e6f8-46c6-8374-0f158e717c70@github.com>
 <CAB84uBUN6Lianhw0RjznXaztr3dy1P0ZM-OwKWCZd=U7MQsxKA@mail.gmail.com>
 <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com>
 <CAB84uBVOnFw4_pcwsioKmw-pBbQJRHQW3Wqstoxa+GGe7aj04Q@mail.gmail.com>
 <CAB84uBVQGGY4SA1Nzs0ZHW7gcHPHJ1OX00YtVygz=EiaaOvVsw@mail.gmail.com>
Message-ID: <CAB84uBV_=vNyryinYEVZAW7bgZfo8vvQezCMiaL1kjEo66eS=w@mail.gmail.com>

On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn <jcorvel at gmail.com> wrote:
>
> On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn <jcorvel at gmail.com> wrote:
> >
> > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth
> > <kevin.rushforth at oracle.com> wrote:
> > >
> > > Gluon maintains JavaFX 17 and 21, so Johan can answer that.
> > >
> > > There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK.
> >
> > Ah yes, for 8 we use the Oracle JDK which includes its JavaFX build.
> > So for backport to Oracle Java 8 I guess we'd need to ask Oracle.
> >
> > Having this fix backported into OpenJFX 17 and 21 would be great though.
>
> Coming back to this: any chance this fix could be backported to
> OpenJFX 17 and 21?

One last try: anyone able to backport this deadkey fix to 17 and 21?
Or even take it into consideration for inclusion in OpenJFX 11 or JDK
8?

-- 
Johan

From johan at lodgon.com  Tue Nov  5 10:59:03 2024
From: johan at lodgon.com (Johan Vos)
Date: Tue, 5 Nov 2024 11:59:03 +0100
Subject: Integrated: 8340982: [win] Dead key followed by Space generates
 two characters instead of one
In-Reply-To: <CAB84uBV_=vNyryinYEVZAW7bgZfo8vvQezCMiaL1kjEo66eS=w@mail.gmail.com>
References: <PyljFPympx4RWe_rxfGQt1cx8FDg-Vwp-vzIbprOe54=.2d8f387e-5b55-4b9c-92ae-5f4995a7aae3@github.com>
 <AJ-GDGQM5PpeJ3rJWwqnf5celujc0dBJcVxxn6tdApw=.360a16d5-e6f8-46c6-8374-0f158e717c70@github.com>
 <CAB84uBUN6Lianhw0RjznXaztr3dy1P0ZM-OwKWCZd=U7MQsxKA@mail.gmail.com>
 <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com>
 <CAB84uBVOnFw4_pcwsioKmw-pBbQJRHQW3Wqstoxa+GGe7aj04Q@mail.gmail.com>
 <CAB84uBVQGGY4SA1Nzs0ZHW7gcHPHJ1OX00YtVygz=EiaaOvVsw@mail.gmail.com>
 <CAB84uBV_=vNyryinYEVZAW7bgZfo8vvQezCMiaL1kjEo66eS=w@mail.gmail.com>
Message-ID: <CAK7C+XgS1Reo1hGWbpw=uE-DsSAZqCbBNnAv77Y+3WogLDgDuQ@mail.gmail.com>

Hi Johan,

Sorry for not replying earlier.
Since this is a real small fix, I think it makes sense to backport it to
17/21.
I'm a bit hesitant because of JEP 14 [1] and the current discussions on the
Tip&Tail approach [2] , where it is explicitly discouraged to backport
anything apart from vulnerabilities and critical errors. Since this is a P4
bug, I don't think it qualifies -- hence my doubt.

This is a situation that I believe could be discussed in jdk-dev -- not for
this issue in particular, but rather the principle: what is the
recommendation with backport requests for P4 bugs that are "small" and
"guaranteed to have no regression"?

I don't think it's good to have the discussion at 2 places, but to
summarize some of the key reasons on why not backporting
non-criticial things:
* we do not want to break existing work in LTS releases (software that
relies on some undocumented internal JavaFX behavior might go wrong if the
behavior is changed)
* we need to make sure the CPU fixes can "easily" be backported.
* time spent in tail-backporting can not be spent in tip-development. And
unfortunately, I learned the hard way that backporting is much more
time-consuming (and error-prone) than I hoped for.

Having said that, I definitely don't want to reject this upfront -- just
want to clarify the complexity and I very much welcome other input.

- Johan

[1]  https://openjdk.org/jeps/14
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009433.html


Op di 5 nov 2024 om 11:40 schreef Johan Corveleyn <jcorvel at gmail.com>:

> On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn <jcorvel at gmail.com> wrote:
> >
> > On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn <jcorvel at gmail.com>
> wrote:
> > >
> > > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth
> > > <kevin.rushforth at oracle.com> wrote:
> > > >
> > > > Gluon maintains JavaFX 17 and 21, so Johan can answer that.
> > > >
> > > > There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK.
> > >
> > > Ah yes, for 8 we use the Oracle JDK which includes its JavaFX build.
> > > So for backport to Oracle Java 8 I guess we'd need to ask Oracle.
> > >
> > > Having this fix backported into OpenJFX 17 and 21 would be great
> though.
> >
> > Coming back to this: any chance this fix could be backported to
> > OpenJFX 17 and 21?
>
> One last try: anyone able to backport this deadkey fix to 17 and 21?
> Or even take it into consideration for inclusion in OpenJFX 11 or JDK
> 8?
>
> --
> Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/6444e454/attachment.htm>

From kcr at openjdk.org  Tue Nov  5 13:23:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 13:23:33 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass
In-Reply-To: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
Message-ID: <I1b3EMHmpwPeCkQ7x9rF-e5WyrEO2-2TgvUM2feP_bw=.a361da1b-30c6-455d-b501-d87313bd9b4d@github.com>

On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> I have removed reference to all AccessControl** class except in Accessible.java assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

Yes, I will remove this as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), which is in progress.

Reviewers: @kevinrushforth @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1624#issuecomment-2457170092

From kcr at openjdk.org  Tue Nov  5 14:33:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 14:33:40 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass
In-Reply-To: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
Message-ID: <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>

On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
> 
> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
> 
> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

I see one problem in Accessibility. To reproduce, run any program that has controls, e.g., HelloTextArea, on either macOS or Windows and turn on the screen reader (VoiceOver on Mac or Narrator on Windows).

You will get a continuous stream of the exceptions, for example on macOS:


Exception in thread "JavaFX Application Thread" java.lang.ClassCastException: class com.sun.glass.ui.Accessible$GetAttribute cannot be cast to class javafx.scene.AccessibleRole (com.sun.glass.ui.Accessible$GetAttribute and javafx.scene.AccessibleRole are in module javafx.graphics at 24-internal of loader 'app')
	at javafx.graphics at 24-internal/com.sun.glass.ui.mac.MacAccessible.getNativeAccessible(MacAccessible.java:832)
	at javafx.graphics at 24-internal/com.sun.glass.ui.View.getAccessible(View.java:1128)


The rest looks good. I left a couple minor comment and a note for @johanvos asking if he wants to review the /ios/ file.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Accessible.java line 169:

> 167:             getAttribute.attribute = attribute;
> 168:             getAttribute.parameters = parameters;
> 169:             return getAttribute;

This needs to be `getAttribute.get()` to be equivalent to the previous code.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkRobot.java line 47:

> 45:         boolean isOnWayland = ((Supplier<Boolean>) () -> {
> 46:             String waylandDisplay = System.getenv("WAYLAND_DISPLAY");
> 47:             return waylandDisplay != null && !waylandDisplay.isBlank();

Minor: the Supplier seems unnecessary here, so this could be further simplified as:


        String waylandDisplay = System.getenv("WAYLAND_DISPLAY");
        boolean isOnWayland = waylandDisplay != null && !waylandDisplay.isBlank();

modules/javafx.graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java line 40:

> 38:     private static native void _initIDs(); // init IDs for java callbacks from native
> 39:     static {
> 40:         Application.loadNativeLibrary();

@johanvos This looks good to me, but since it is in ios code, do you want to check it as well?

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

> 128:                 return  !"false".equalsIgnoreCase(taskbarAppProp);
> 129:             }).get();
> 130:         isTaskbarApplication = tmp;

Minor: I think this can be further simplified by removing the `tmp` variable and the `Supplier` and assigning `isTaskbarApplication` directly on line 128.

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

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2415656981
PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1829443237
PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1829369148
PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1829373735
PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1829376484

From kcr at openjdk.org  Tue Nov  5 14:42:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 14:42:38 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass
In-Reply-To: <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>
Message-ID: <EQJSDXvaab9wzmEOcG-6n6MOdBB0XFDbUm1XkJou_XM=.95f2a020-635a-460b-93db-864b4562cc94@github.com>

On Tue, 5 Nov 2024 14:23:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Accessible.java line 169:
> 
>> 167:             getAttribute.attribute = attribute;
>> 168:             getAttribute.parameters = parameters;
>> 169:             return getAttribute;
> 
> This needs to be `getAttribute.get()` to be equivalent to the previous code.

Alternatively, the following would work and be simpler, if you prefer:


    public Object getAttribute(AccessibleAttribute attribute, Object... parameters) {
        getAttribute.attribute = attribute;
        getAttribute.parameters = parameters;
        return QuantumToolkit.runWithoutRenderLock(getAttribute);
    }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1829472345

From kevin.rushforth at oracle.com  Tue Nov  5 15:01:47 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 5 Nov 2024 07:01:47 -0800
Subject: =?UTF-8?Q?CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
Message-ID: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>

I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.

Michael is an OpenJFX community member, who has contributed 41 commits 
[2] to OpenJFX. Michael regularly participates in code reviews, 
especially in the areas of JavaFX scene graph, graphics, and UI 
controls, offering valuable feedback.

Votes are due by Nov 19, 2024 at 16:00 UTC.

Only current OpenJFX Reviewers [3] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4]. Nomination to a 
project Reviewer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#mstrauss

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#three-vote-consensus

[5] https://openjdk.java.net/projects#project-reviewer


From kevin.rushforth at oracle.com  Tue Nov  5 15:02:24 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 5 Nov 2024 07:02:24 -0800
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <42acc8ca-0c92-4241-bb87-d84bb91d0b1b@oracle.com>

Vote: YES


On 11/5/2024 7:01 AM, Kevin Rushforth wrote:
> I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.

From nlisker at gmail.com  Tue Nov  5 15:05:08 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 5 Nov 2024 17:05:08 +0200
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <42acc8ca-0c92-4241-bb87-d84bb91d0b1b@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
 <42acc8ca-0c92-4241-bb87-d84bb91d0b1b@oracle.com>
Message-ID: <CA+0ynh_kji2No4PGW4gDfxSvwqubJiWpXYGHaU4NmH4yh+q3_w@mail.gmail.com>

Vote: YES

On Tue, Nov 5, 2024 at 5:02?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Vote: YES
>
>
> On 11/5/2024 7:01 AM, Kevin Rushforth wrote:
> > I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/ce8a45e6/attachment.htm>

From andy.goryachev at oracle.com  Tue Nov  5 15:28:48 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 5 Nov 2024 15:28:48 +0000
Subject: =?iso-8859-1?Q?Re:_CFV:_New_OpenJFX_Reviewer:_Michael_Strau=DF?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <BL3PR10MB6185484C50052D4F4C9ED92FE5522@BL3PR10MB6185.namprd10.prod.outlook.com>

Vote: YES


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, November 5, 2024 at 07:02
To: openjfx-dev <openjfx-dev at openjdk.org>, Michael Strau? <michaelstrau2 at gmail.com>
Subject: CFV: New OpenJFX Reviewer: Michael Strau?
I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.

Michael is an OpenJFX community member, who has contributed 41 commits
[2] to OpenJFX. Michael regularly participates in code reviews,
especially in the areas of JavaFX scene graph, graphics, and UI
controls, offering valuable feedback.

Votes are due by Nov 19, 2024 at 16:00 UTC.

Only current OpenJFX Reviewers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4]. Nomination to a
project Reviewer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#mstrauss

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#three-vote-consensus

[5] https://openjdk.java.net/projects#project-reviewer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/acc7670f/attachment.htm>

From angorya at openjdk.org  Tue Nov  5 15:58:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 15:58:38 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <WkrsybmHI5uQaZmarE6YagSzAl19r9tdDOMkawG_Zrs=.f4469fda-5c2e-4e4c-9106-bcd552451d18@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <WkrsybmHI5uQaZmarE6YagSzAl19r9tdDOMkawG_Zrs=.f4469fda-5c2e-4e4c-9106-bcd552451d18@github.com>
Message-ID: <hgiaW-hUbAj0tc0687uFAl2I6tyVClemi_vf66nzEKo=.915f97d4-e355-4d4b-9dd2-2c5de6861dff@github.com>

On Tue, 5 Nov 2024 01:06:25 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 78:
>> 
>>> 76:  *
>>> 77:  * <table style="white-space: nowrap">
>>> 78:  *     <caption>CSS properties of {@code window-button-container}</caption>
>> 
>> The new CSS properties need to be included in `cssref.html`, along with the description of platform availability.
>> 
>> Should this be done as part of this PR?  (that would be my preference)
>
> `WindowControlsOverlay` is not API, it's an implementation detail and as such must not be documented in `cssref.html`. This is by design: currently, this feature has a minimal API with just three new API elements: `StageStyle.EXTENDED`, `HeaderBar`, and `HeaderBarBase`. If we allowed app developers to customize window buttons, the API would explode in size and the specification burden would be immense. Let's not go there.

I am confused.  Can it be customized with a style sheet?  If so, it should be documented, no?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829607426

From angorya at openjdk.org  Tue Nov  5 16:01:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 16:01:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <mbqF2lVG2ly9I7bwQG8jXGH_1HqlYRgA2t2DwPR1Olg=.873ea217-2cdf-4af0-9c6a-74a566587dc4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <mbqF2lVG2ly9I7bwQG8jXGH_1HqlYRgA2t2DwPR1Olg=.873ea217-2cdf-4af0-9c6a-74a566587dc4@github.com>
Message-ID: <28zO6gn08JUaHWS0Pvg04vVBurhE8NXDqYI6VIXSKMM=.1af6c197-653f-462b-9a48-56258f7404b1@github.com>

On Tue, 5 Nov 2024 01:11:24 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 104:
>> 
>>> 102:  *     </thead>
>>> 103:  *     <tbody><tr>
>>> 104:  *         <th>-fx-button-order</th><td>&lt;integer&gt;</td><td>0/1/2</td>
>> 
>> what happens when CSS sets all buttons to the same value?
>> should this be something that user has control over vs. defined by the platform?
>
> The buttons are sorted with `List.sort`, so that will dictate what happens in this scenario. Note that this class is not API, and neither users nor the platform will have any control over it.

since it's still javadoc, I'll continue.   The value is specified as 0/1/2 yet I can't see any validation of that (I suspect any value would work and be sorted as you mentioned).   What gives?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829611983

From mstrauss at openjdk.org  Tue Nov  5 16:06:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 16:06:38 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <hgiaW-hUbAj0tc0687uFAl2I6tyVClemi_vf66nzEKo=.915f97d4-e355-4d4b-9dd2-2c5de6861dff@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <WkrsybmHI5uQaZmarE6YagSzAl19r9tdDOMkawG_Zrs=.f4469fda-5c2e-4e4c-9106-bcd552451d18@github.com>
 <hgiaW-hUbAj0tc0687uFAl2I6tyVClemi_vf66nzEKo=.915f97d4-e355-4d4b-9dd2-2c5de6861dff@github.com>
Message-ID: <ooy5qrjVePwnLWvnFaCUW4ugv8K3k8mU5gCTQgXC1oY=.32ba8a5a-e9a2-4ebe-89b8-7cb810d89140@github.com>

On Tue, 5 Nov 2024 15:56:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `WindowControlsOverlay` is not API, it's an implementation detail and as such must not be documented in `cssref.html`. This is by design: currently, this feature has a minimal API with just three new API elements: `StageStyle.EXTENDED`, `HeaderBar`, and `HeaderBarBase`. If we allowed app developers to customize window buttons, the API would explode in size and the specification burden would be immense. Let's not go there.
>
> I am confused.  Can it be customized with a style sheet?  If so, it should be documented, no?

It can't be customized by users, as there is no API for that. There wouldn't be a platform-independent way to do that, because we're not using `WindowControlsOverlay` on macOS in the first place.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829620784

From angorya at openjdk.org  Tue Nov  5 16:06:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 16:06:39 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <WlzbSwKVGAX-YSZ0gXAndpcDeNSguDwnLr5BqtjyAGQ=.8818e934-0f56-4d7e-b8fb-9aae6d832ecc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <WlzbSwKVGAX-YSZ0gXAndpcDeNSguDwnLr5BqtjyAGQ=.8818e934-0f56-4d7e-b8fb-9aae6d832ecc@github.com>
Message-ID: <-YeVTaL1601H03g_o-FLKu06lUJxMGP0mgptB2v6CUw=.0386d838-e04f-474f-9500-a22d54d899dc@github.com>

On Tue, 5 Nov 2024 01:13:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 199:
>> 
>>> 197:      */
>>> 198:     private final StyleableBooleanProperty allowRtl =
>>> 199:         new SimpleStyleableBooleanProperty(ALLOW_RTL_METADATA, this, "allowRtl", true) {
>> 
>> why is `allowRtl` a property and not a simple flag?
>> why is it allowed to be changed via CSS via `-fx-allow-rtl`?
>
> The purpose is to allow JavaFX developers (that is us, not users of JavaFX) to define the entire appearance of `WindowControlsOverlay` with a CSS file. This should make it easier to maintain it, since we won't have to keep looking in two places to change the appearance.

I don't understand: why the orientation of EXTENDED window be different from that of the platform (unless explicitly configured with Scene.nodeOrientation)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829620861

From angorya at openjdk.org  Tue Nov  5 16:11:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 16:11:43 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <YuUsyV8PYaBQfbksDFjtNjDdjftc7OrcHdazT7NlbOk=.1c58876c-902f-4f00-bd87-6893b3f3d8de@github.com>
 <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com>
Message-ID: <5ksteP0TOR1uE0DXvHmgIYus2rZRb2fz_MxKU_XAcD4=.5f0404da-4494-4d65-a468-425c7998e816@github.com>

On Tue, 5 Nov 2024 01:23:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> would it be possible to specify where from?
>
> Yes, but if we do that, then we should do it everywhere it matters. The native toolkits are not multi-threaded, so all native upcalls happen on the JavaFX application thread. We should probably do this in another PR, and discuss how to do it uniformly (javadoc, annotation, etc).

I think it would make sense to start doing this in the new code, as this helps to show the connection.  Only if as a courtesy to the developers who have to read the code years later.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829628675

From mstrauss at openjdk.org  Tue Nov  5 16:15:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 16:15:39 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <-YeVTaL1601H03g_o-FLKu06lUJxMGP0mgptB2v6CUw=.0386d838-e04f-474f-9500-a22d54d899dc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <WlzbSwKVGAX-YSZ0gXAndpcDeNSguDwnLr5BqtjyAGQ=.8818e934-0f56-4d7e-b8fb-9aae6d832ecc@github.com>
 <-YeVTaL1601H03g_o-FLKu06lUJxMGP0mgptB2v6CUw=.0386d838-e04f-474f-9500-a22d54d899dc@github.com>
Message-ID: <_jVCvMDDEO3nC_DUSPdKjh3fTv___Wkz1FtOR1yjrbU=.618f0d90-64ff-428f-9d6c-4be8509eadc7@github.com>

On Tue, 5 Nov 2024 16:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The purpose is to allow JavaFX developers (that is us, not users of JavaFX) to define the entire appearance of `WindowControlsOverlay` with a CSS file. This should make it easier to maintain it, since we won't have to keep looking in two places to change the appearance.
>
> I don't understand: why the orientation of EXTENDED window be different from that of the platform (unless explicitly configured with Scene.nodeOrientation)?

When `-fx-allow-rtl` is set and the node orientation is RTL, the window buttons move to the other side of the window. This is a bit of a stylistic decision that may depend on OS and window manager. Maybe some window managers don't do that, and instead always keep the window buttons on the same side. This if kind of future-proofing the `WindowControlsOverlay` control.
Let's say that in the future, a popular Linux window manager emerges that has a very distinct look and always keeps the window buttons on the same side. Then supporting this window manager will be as easy as providing an appropriate CSS file for its look-and-feel, all without changing the `WindowControlsOverlay` control.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829634347

From mstrauss at openjdk.org  Tue Nov  5 16:24:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 16:24:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <28zO6gn08JUaHWS0Pvg04vVBurhE8NXDqYI6VIXSKMM=.1af6c197-653f-462b-9a48-56258f7404b1@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <mbqF2lVG2ly9I7bwQG8jXGH_1HqlYRgA2t2DwPR1Olg=.873ea217-2cdf-4af0-9c6a-74a566587dc4@github.com>
 <28zO6gn08JUaHWS0Pvg04vVBurhE8NXDqYI6VIXSKMM=.1af6c197-653f-462b-9a48-56258f7404b1@github.com>
Message-ID: <qSqioJerDq4lzft8tSkZoowU3O3XKqNim8xEdXggwvs=.47257ce1-679e-428f-949d-49c4732d38b7@github.com>

On Tue, 5 Nov 2024 15:59:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The buttons are sorted with `List.sort`, so that will dictate what happens in this scenario. Note that this class is not API, and neither users nor the platform will have any control over it.
>
> since it's still javadoc, I'll continue.   The value is specified as 0/1/2 yet I can't see any validation of that (I suspect any value would work and be sorted as you mentioned).   What gives?

Any value will work. This is the javadoc for `buttonOrder`:

        /**
         * Specifies the layout order of this button relative to the other buttons.
         * Buttons with a lower value are laid out before buttons with a higher value.
         * <p>
         * This property corresponds to the {@code -fx-button-order} CSS property.
         */

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829647038

From mstrauss at openjdk.org  Tue Nov  5 16:24:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 16:24:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <5ksteP0TOR1uE0DXvHmgIYus2rZRb2fz_MxKU_XAcD4=.5f0404da-4494-4d65-a468-425c7998e816@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <YuUsyV8PYaBQfbksDFjtNjDdjftc7OrcHdazT7NlbOk=.1c58876c-902f-4f00-bd87-6893b3f3d8de@github.com>
 <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com>
 <5ksteP0TOR1uE0DXvHmgIYus2rZRb2fz_MxKU_XAcD4=.5f0404da-4494-4d65-a468-425c7998e816@github.com>
Message-ID: <tPQHk6dJ_42B7oZo9FiA6K8xXDGeVlygRrePp9GrDfs=.6878ecb3-3c26-44d9-96dd-5bd6fb2b5cba@github.com>

On Tue, 5 Nov 2024 16:09:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, but if we do that, then we should do it everywhere it matters. The native toolkits are not multi-threaded, so all native upcalls happen on the JavaFX application thread. We should probably do this in another PR, and discuss how to do it uniformly (javadoc, annotation, etc).
>
> I think it would make sense to start doing this in the new code, as this helps to show the connection.  Only if as a courtesy to the developers who have to read the code years later.

Maybe so, but let's not discuss this in this PR. It's probably best to have a discussion on the mailing list first, and come up with a consistent way of documenting native upcalls.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829649238

From duke at openjdk.org  Tue Nov  5 16:52:39 2024
From: duke at openjdk.org (PavelTurk)
Date: Tue, 5 Nov 2024 16:52:39 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v36]
In-Reply-To: <vd-oi9l8L4CE0jfbCu4VEJwY2iMWBEJqHnBgl2-TURM=.a4cf642a-91e2-4845-8510-7cc0ba1d320c@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vd-oi9l8L4CE0jfbCu4VEJwY2iMWBEJqHnBgl2-TURM=.a4cf642a-91e2-4845-8510-7cc0ba1d320c@github.com>
Message-ID: <IzqFhWU1Owx_dMbA93D9O4zY18w-_6BV2AKV9j1NSBE=.1e27bec7-56a1-438b-bb59-a2d5248fbe05@github.com>

On Fri, 1 Nov 2024 23:12:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Currently we use RichTextFX and the problem is that it doesn't support caret form (see https://github.com/FXMisc/RichTextFX/issues/1121) . I've just checked RichTextArea CSS guide and found there `-fx-caret-blink-period`. I suggest to add at least `-fx-caret-shape` with all well-known shapes, like bar etc. Besides `-fx-caret-color` would be nice.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2457684515

From nlisker at gmail.com  Tue Nov  5 17:22:29 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 5 Nov 2024 19:22:29 +0200
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <BL3PR10MB61852F462E7A82AF406DF35FE54A2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <BL3PR10MB61852F462E7A82AF406DF35FE54A2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh_zoqpJGRnhip4KmeUaLYK=5fQMKUmtkkkQSMd=V6J+_w@mail.gmail.com>

By the way, I came across this project:
https://github.com/xdsswar/nfx-lib?tab=readme-ov-file. It's only for
Windows, but allows manipulation of the title bar. Might be good to compare
with in terms of functionality.

On Mon, Oct 28, 2024 at 8:27?PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Dear Michael:
>
>
>
> Could you add another row to the table in the JEP clarifying who is
> responsible for the application title?
>
>
>
> I would like to suggest to include this table in the javadoc - where do
> you think it should be?  HeaderBar?
>
>
>
> Thanks,
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael
> Strau? <michaelstrau2 at gmail.com>
> *Date: *Tuesday, October 22, 2024 at 16:55
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *JEP: JavaFX controls in the title bar
>
> Hi everyone,
>
> the discussion in PR #1605 has shown that the proposed feature needs a
> better presentation in a JEP-like format, so here it is:
>
> https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/c86a4840/attachment.htm>

From arapte at openjdk.org  Tue Nov  5 17:47:04 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Nov 2024 17:47:04 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base
Message-ID: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>

Remove `doPrivileged` calls in the javafx.base module.
The changes are straight forward.
1. Remove doPrivileged calls, with keeping the lambda expression.
2. Remove SuppressWarnings annotations
3. Remove unused imports

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

Commit messages:
 - rm doPrivileged in javafx.base

Changes: https://git.openjdk.org/jfx/pull/1625/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342459
  Stats: 376 lines in 20 files changed: 17 ins; 159 del; 200 mod
  Patch: https://git.openjdk.org/jfx/pull/1625.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1625/head:pull/1625

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

From kcr at openjdk.org  Tue Nov  5 17:54:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 17:54:38 GMT
Subject: Integrated: 8342917: GHA: Intermittent build failure on Linux while
 downloading ant
In-Reply-To: <Rm4H39dOLBOYV-OmhnBU1hcOsPmxVIkaWPhIjcNT8zM=.32610c67-d7c0-47b3-a456-cde2d70c66ad@github.com>
References: <Rm4H39dOLBOYV-OmhnBU1hcOsPmxVIkaWPhIjcNT8zM=.32610c67-d7c0-47b3-a456-cde2d70c66ad@github.com>
Message-ID: <vukhSyYbCnFbPyIsa9WdgUIX1We9o6OvuY6CG2o7Jgw=.ef4fea3e-74c7-44a8-83b6-6e86eb4c75f3@github.com>

On Mon, 4 Nov 2024 17:42:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We are getting frequent intermittent failures downloading `ant` on Linux. The fix is to use the package manager to install ant rather than downloading it from `apache.org`.
> 
> This only impacts GHA test builds, so the only verification needed for this fix is that the GHA build passes on all platforms.

This pull request has now been integrated.

Changeset: caf078ac
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/caf078acd42fabc3d9746471b54a77f3b86ff305
Stats:     14 lines in 1 file changed: 3 ins; 0 del; 11 mod

8342917: GHA: Intermittent build failure on Linux while downloading ant

Reviewed-by: jvos

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

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

From angorya at openjdk.org  Tue Nov  5 17:56:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 17:56:41 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v36]
In-Reply-To: <IzqFhWU1Owx_dMbA93D9O4zY18w-_6BV2AKV9j1NSBE=.1e27bec7-56a1-438b-bb59-a2d5248fbe05@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vd-oi9l8L4CE0jfbCu4VEJwY2iMWBEJqHnBgl2-TURM=.a4cf642a-91e2-4845-8510-7cc0ba1d320c@github.com>
 <IzqFhWU1Owx_dMbA93D9O4zY18w-_6BV2AKV9j1NSBE=.1e27bec7-56a1-438b-bb59-a2d5248fbe05@github.com>
Message-ID: <ulZeOzp3xDBIAMssOPBJIhFbj2u0QcrT4hm5z5qnuMI=.44939b07-cf94-48c8-8db0-feeac0b80404@github.com>

On Tue, 5 Nov 2024 16:48:04 GMT, PavelTurk <duke at openjdk.org> wrote:

> I suggest to add at least `-fx-caret-shape` with all well-known shapes, like bar etc. Besides `-fx-caret-color` would be nice.

Thank you for the feedback!

I wanted not to complicate the first round with different carets.  Nevertheless, it should be possible to either support some of the caret types out of the box, or allow for customization.

The default caret shape may need to depend on the input locale and/or presence of RTL or mixed text - something is yet to be fully addressed due to existing bugs, see https://bugs.openjdk.org/browse/JDK-8343557

Another topic is the "block caret", which, in my opinion, only makes sense with the monospaced font, maybe in the `CodeArea`.  I don't know how the block caret should look with the proportional fonts, or when navigating grapheme clusters (a bit of a pain point at the moment).

And lastly, `.caret` is a Path, so it can be styled with the CSS, see RichTextAreaDemoPane:183
I don't know whether additional styleable property is needed, since the app can just use the stylesheet or inline style, but I can be wrong.

Also (you know this already, but the wider audience may not): there is ongoing work in https://bugs.openjdk.org/browse/JDK-8341670 to expose more detail about the caret geometry (among other things) that should help third party devs with creating custom carets.

Thanks again!

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2457824168

From kcr at openjdk.org  Tue Nov  5 18:01:03 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 18:01:03 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
Message-ID: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>

This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.

As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).

The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:

1. It will minimize the changes to native WebKit JNI code.
2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.

This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).

NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

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

Commit messages:
 - Merge branch 'master' into 8343630-acc-native-webkit
 - 8343630: Pass AccessControlContext to/from WebKit as opaque object

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

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

From kcr at openjdk.org  Tue Nov  5 18:07:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 18:07:33 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
Message-ID: <aA0fXl2m5JHIe4dY2684CyGu4qMfNCkJDyLhM1Q3vcI=.7b8f76d5-596e-4e2f-a6b2-9f1d5df4ece5@github.com>

On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.
> 
> As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:
> 
> 1. It will minimize the changes to native WebKit JNI code.
> 2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.
> 
> This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).
> 
> NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

Reviewers: @jaybhaskar and either @andy-goryachev-oracle or @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1626#issuecomment-2457846350

From kcr at openjdk.org  Tue Nov  5 18:15:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 18:15:33 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
Message-ID: <FURZUl-qf6Hft9F49GURRT9KC7RXfSaA6tLxshu8tcs=.864f3b96-23bb-4128-aacb-75f3aee94929@github.com>

On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.
> 
> As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:
> 
> 1. It will minimize the changes to native WebKit JNI code.
> 2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.
> 
> This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).
> 
> NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

When testing this, you will need to build the native webkit. If you use a previously-built webkit library it will crash.

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

PR Comment: https://git.openjdk.org/jfx/pull/1626#issuecomment-2457859429

From tsayao at openjdk.org  Tue Nov  5 18:23:37 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 5 Nov 2024 18:23:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <Tk4e_cE4kedixu2kGpxOrZtc_ynJSqZwQfsoWanTsi0=.f1940035-f2ae-4fd8-89b2-9637da8d1833@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <Tk4e_cE4kedixu2kGpxOrZtc_ynJSqZwQfsoWanTsi0=.f1940035-f2ae-4fd8-89b2-9637da8d1833@github.com>
Message-ID: <j_mIK0MsUzUte7sKK0EP_0uFyzdkcwwXDA540SGnspM=.6f4c22d3-f110-4a59-92ec-7966835e825b@github.com>

On Tue, 5 Nov 2024 01:40:34 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> > I'm not sure if it's feasible, but having a `GtkOverlay` seems to work on a basic app paintable C app:
> > Gtk4 even has [WindowControls](https://docs.gtk.org/gtk4/class.WindowControls.html).
> > I started to play with the CSS to make it transparent, but it does not seem much straightforward, but possible.
> > Running the program with `GTK_DEBUG=interactive` makes it easier.
> 
> The main problem with this approach is that it presupposes that the drawing is only done in GTK callbacks. But that's not how JavaFX interacts with GTK, so I think it will probably not work. I haven't found a way to simultaneously use the current JavaFX rendering approach and mix in GTK widgets on the same surface.

Yeah, didn't work. In theory it should work with Wayland and a subsurface, like [libdecor](https://gitlab.freedesktop.org/libdecor/libdecor) does. X11 has the concept of multiple stacked Windows, in theory it's possible, I just don't know how to sync it.

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

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

From kcr at openjdk.org  Tue Nov  5 18:39:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 18:39:35 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base
In-Reply-To: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
Message-ID: <3aY-MVVWVOOTnoXtYMxmA2jbARdtimTU0APYGoev1nA=.9533d9f7-5eb9-4d49-9637-f7aa86cb08fa@github.com>

On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Remove `doPrivileged` calls in the javafx.base module.
> The changes are straight forward.
> 1. Remove doPrivileged calls, with keeping the lambda expression.
> 2. Remove SuppressWarnings annotations
> 3. Remove unused imports

> Pre-submit tests - Linux x64 - Build / test Failing after 3m ? 1/1 failed

I just integrated the fix for this, so if you merge in the latest master, you won't see this problem any more.

Reviewers: @kevinrushforth @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1625#issuecomment-2457900519

From kcr at openjdk.org  Tue Nov  5 19:04:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 19:04:41 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base
In-Reply-To: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
Message-ID: <sB3pIabGawj_r2z2AhLTK36e2744xqxwmx_8GSoWQzk=.15f9e5b5-c6ad-4df1-9545-b63bb1e2d49f@github.com>

On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Remove `doPrivileged` calls in the javafx.base module.
> The changes are straight forward.
> 1. Remove doPrivileged calls, with keeping the lambda expression.
> 2. Remove SuppressWarnings annotations
> 3. Remove unused imports

Looks good. I did leave one inline comment: I think there is a now-unused private `AccessControllerContext` field in the various `*JavaBeans*` classes. If so, removing that unused field will also allow removing the remaining `SuppressWarnings` annotation and the last of the security-related imports.

If you decide to change this I will reapprove. Otherwise, I'll pick it up in the last of the follow-up fixes.

modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanProperty.java line 42:

> 40: import java.security.AccessControlContext;
> 41: import java.security.AccessController;
> 42: import java.security.PrivilegedAction;

I think you can remove the now-unused field `private final AccessControlContext acc`, which will also let you remove the `AccessControlContext` and  `AccessController`. Alternatively, I will remove them as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).

This comment applies to all of the `JavaBeanXXXProperty` classes.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1625#pullrequestreview-2416449407
PR Review Comment: https://git.openjdk.org/jfx/pull/1625#discussion_r1829854754

From kcr at openjdk.org  Tue Nov  5 19:49:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 19:49:12 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated methods
Message-ID: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>

As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.

This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.

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

Commit messages:
 - 8342992: Security manager check should not use deprecated methods

Changes: https://git.openjdk.org/jfx/pull/1627/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342992
  Stats: 89 lines in 5 files changed: 77 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1627.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1627/head:pull/1627

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

From angorya at openjdk.org  Tue Nov  5 19:59:54 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 19:59:54 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
Message-ID: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>

On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stylistic changes

second batch of comments

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 118:

> 116: 
> 117:     private static final String ALIGNMENT = "headerbar-alignment";
> 118:     private static final String MARGIN = "headerbar-margin";

Q: should these be a String or an Object?  String.equals() are more expensive.

(I guess we use Strings elsewhere, so probably ok).

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 170:

> 168:         // Inflate the minHeight property. This is important so that we can track whether a stylesheet or
> 169:         // user code changes the property value before we set it to the height of the native title bar.
> 170:         minHeightProperty();

if that's the case, why not initialize it in L1150 ?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 262:

> 260:     @Override
> 261:     protected double computeMinWidth(double height) {
> 262:         Node leading = getLeading(), center = getCenter(), trailing = getTrailing();

I think it's a bad practice to have multiple statements on one line.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 51:

> 49:  * can specify draggable content nodes of the {@code HeaderBarBase} with the {@link #setDraggable} method.
> 50:  *
> 51:  * @apiNote Most application developers should use the {@link HeaderBar} implementation instead of

just curious: what's the reason to split the HB into the two classes?  Can you give an example?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 138:

> 136:     private void updateInsets() {
> 137:         if (currentFullScreen || currentMetrics == null) {
> 138:             leftSystemInset.set(new Dimension2D(0, 0));

Q: would it make sense to declare a
`static final Dimension2D EMPTY = new Dimension2D(0, 0)`
and use it everywhere?

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 190:

> 188:      * independent of layout orientation.
> 189:      */
> 190:     private final ReadOnlyObjectWrapper<Dimension2D> rightSystemInset =

Q: would it make sense to create a class with requestLayout() ?  this will save two class objects...

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 83:

> 81:      * <p>
> 82:      * An extended window has the default window buttons (minimize, maximize, close), but no system-provided
> 83:      * draggable header bar. Applications need to provide their own header bar by placing a single {@link HeaderBar}

I would like to see this expanded just a little bit, to give an example of what is (system menu, buttons) and is not rendered (rounded corners, app title), similarly to the the table in the JEP.

I would prefer a table or an `<ul>`, and I specifically want to include the window title.  Window title is a property, and I think it deserves a mention (will it be shown in the tray? in the "running applications" os widget?)

I don't know whether the best place to include that is here or in the `HeaderBar`.

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1336:

> 1334: }
> 1335: 
> 1336: - (NSEvent*)lastEvent

could there be side effects with exposing this field?
concurrency issues?

modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 26:

> 24:  */
> 25: 
> 26: .window-button-container {

is it possible for the app dev to alter the styling with an external style sheet?

modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 125:

> 123: 
> 124: .close-button > .glyph {
> 125:     -fx-shape: "m 8.1464844,8.1464844 a 0.5,0.5 0 0 0 0,0.7070312 L 11.292969,12 8.1464844,15.146484 a 0.5,0.5 0 0 0 0,0.707032 0.5,0.5 0 0 0 0.7070312,0 L 12,12.707031 l 3.146484,3.146485 a 0.5,0.5 0 0 0 0.707032,0 0.5,0.5 0 0 0 0,-0.707032 L 12.707031,12 15.853516,8.8535156 a 0.5,0.5 0 0 0 0,-0.7070312 0.5,0.5 0 0 0 -0.707032,0 L 12,11.292969 8.8535156,8.1464844 a 0.5,0.5 0 0 0 -0.7070312,0 z";

minor: we could probably minimize the path by rounding to 2 or 3 decimal points
(same comment for all .css changes)

modules/javafx.graphics/src/main/resources/com/sun/glass/ui/win/WindowDecoration.css line 107:

> 105: 
> 106: .maximize-button.restore > .glyph {
> 107:     -fx-shape: "m 7.6491699,2.5192871 q 0,-0.3444824 -0.1369629,-0.6495361 Q 7.3752441,1.5646973 7.1407471,1.338501 6.90625,1.1123047 6.5970459,0.98156738 6.2878418,0.85083008 5.9475098,0.85083008 H 1.7722168 Q 1.838623,0.65991211 1.9589844,0.50219727 2.0793457,0.34448242 2.2370605,0.23242188 2.3947754,0.12036133 2.5836182,0.06018066 2.7724609,0 2.9758301,0 H 5.9475098 Q 6.4746094,0 6.9394531,0.20129395 7.4042969,0.40258789 7.7508545,0.74707031 8.0974121,1.0915527 8.2987061,1.5563965 8.5,2.0212402 8.5,2.5483398 V 5.5241699 Q 8.5,5.7275391 8.4398193,5.9163818 8.3796387,6.1052246 8.2675781,6.2629395 8.1555176,6.4206543 7.9978027,6.5410156 7.8400879,6.661377 7.6491699,6.7277832 Z M 1.253418,8.5 Q 1.0043945,8.5 0.77612305,8.3983154 0.54785156,8.2966309 0.37561035,8.1243896 0.20336914,7.9521484 0.10168457,7.723877 0,7.4956055 0,7.246582 V 2.9550781 Q 0,2.7019043 0.10168457,2.475708 0.20336914,2.2495117 0.37561035,2.0772705 0.54785156,1.9050293 0.77404785,1.8033447 1.0002441,1.70166
 02 1.253418,1.7016602 h 4.2915039 q 0.2531738,0 0.4814453,0.1016845 0.2282715,0.1016846 0.3984375,0.2718506 0.170166,0.170166 0.2718506,0.3984375 0.1016845,0.2282715 0.1016845,0.4814453 V 7.246582 q 0,0.2531739 -0.1016845,0.4793701 Q 6.5949707,7.9521484 6.4227295,8.1243896 6.2504883,8.2966309 6.024292,8.3983154 5.7980957,8.5 5.5449219,8.5 Z M 5.5241699,7.6491699 q 0.087158,0 0.1639405,-0.033203 0.076782,-0.033203 0.1369628,-0.091309 0.060181,-0.058105 0.093384,-0.1348877 0.033203,-0.076782 0.033203,-0.1639404 v -4.25 q 0,-0.087158 -0.033203,-0.1660156 Q 5.8852539,2.730957 5.8271484,2.6728516 5.769043,2.6147461 5.6901855,2.581543 5.6113281,2.5483398 5.5241699,2.5483398 h -4.25 q -0.087158,0 -0.1639404,0.033203 -0.076782,0.033203 -0.1348877,0.093384 -0.0581055,0.060181 -0.0913086,0.1369628 -0.0332031,0.076782 -0.0332031,0.1639405 v 4.25 q 0,0.087158 0.0332031,0.1639404 0.0332031,0.076782 0.0913086,0.1348877 0.0581055,0.058105 0.1348877,0.091309 0.076782,0.033203 0.1639404,0.033203 z";

... especially here

modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HeaderBarTest.java line 70:

> 68:         "BOTTOM_CENTER, 10, 10, 100, 80",
> 69:         "BOTTOM_RIGHT, 10, 10, 100, 80"
> 70:     })

these tests can be simplified to avoid parsing with @CsvSource and default conversion, example:


    @ParameterizedTest
    @CsvSource(value = {"yo,true,1", 
                        "bah,true,1.1", 
                        "meh,false,2.2"})
    void test(String candidate, boolean expected, double a) {
        System.out.println("candidate=" + candidate + " expected=" + expected + " a=" +a );
    }

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

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2416113079
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829669611
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829671987
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829674239
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829687841
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829847752
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829849333
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829857742
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829868608
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829874022
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829875372
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829876147
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829926610

From angorya at openjdk.org  Tue Nov  5 19:59:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 19:59:56 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
Message-ID: <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>

On Tue, 5 Nov 2024 06:00:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java line 156:
>> 
>>> 154:      * Indicates that a system supports {@link javafx.stage.StageStyle#EXTENDED}.
>>> 155:      * <p>
>>> 156:      * This feature is currently supported on Windows, Linux, and macOS.
>> 
>> would it make sense to add more information similarly to UNIFIED_WINDOW on L151?
>> maybe pointing to different levels of support?
>> 
>> I don't know whether it makes sense to bring the whole table from the JEP here, but maybe somewhere (HeaderBar)?
>
> It links directly to `StageStyle.EXTENDED`, which contains lots of information. I don't think we need it here.
> 
> By the way, there are no support levels. The feature is supported in its entirety, as specified, on all desktop platforms. The table in the JEP is just informational to help OpenJFX developers understand what we're talking about. It's not a specification, and it can't be a specification because we either don't control things (for example, we have no influence on rounded corners, this could be changed with any future OS version) or because we'd be specifying us into a corner. There's no point prescribing every minute detail, and then being responsible to keep it working _exactly_ as described, even though the semantics are unchanged.
> 
> The relevant parts are specified in `StageStyle.EXTENDED` and `HeaderBar`, and I wouldn't go further than this. We don't specify the details of `StageStyle.DECORATED` for each OS; why should we do it for `StageStyle.EXTENDED`?

I guess you are right here: from the app dev perspective, there is no difference between the supported platforms.  All good.

I do suggest to bring a condensed version of the table in the JEP (or a simple <ul> here to show what's being painted by the platform and what is not.  In other words, instead of reading 1k of text, I want to see a short list indicating that, for example, close button is painted by the platform, and the title bar is not painted.

Can you do something like this?  (Alternatively, there might be a better place to do that, but where?)

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 53:
>> 
>>> 51:  * account for the default window buttons (minimize, maximize, close). If a child is configured to be
>>> 52:  * centered in the {@code center} area, it is laid out with respect to the stage, and not with respect
>>> 53:  * to the {@code center} area. This ensures that the child will appear centered in the stage regardless
>> 
>> should there be more fine tuned control for growing/shrinking?
>> 
>> can the application just add a single container like GridPane that handles the resizing?
>
> What do you mean with growing and shrinking?
> 
> An application can add a single `GridPane` to `HeaderBar.center`, and set its prefWidth to `POSITIVE_INFINITY`. This will extend the `GridPane` across the entire width of the header bar (excluding the window button area).

maybe what's needed is to borrow some text from the `BorderPane`, along the lines of 

> "The top and bottom children will be resized to their preferred heights and extend the width of the border pane. The left and right children will be resized to their preferred widths and extend the length between the top and bottom nodes. And the center node will be resized to fill the available space in the middle. Any of the positions may be null. "

the important parts are
- how children are resized
- any can be null

(the layout in the HB is like the one in the `BorderPane`, right?)

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 59:
>> 
>>> 57:  * {@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children. If the child's
>>> 58:  * resizable range prevents it from be resized to fit within its position, it will be vertically centered
>>> 59:  * relative to the available space; this alignment can be customized with a layout constraint.
>> 
>> what if the components are too large to fit, will clipping occur?  should this behavior be mentioned?
>
> The components can't be too large to fit:
> `{@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children.`

I want to know what happens when the layout is over-constrained.  For example, consider the layout to have the leading, the center, and the trailing nodes set, and the leading one has minWidth set to 10_000.  What happens?

Will the center and the trailing nodes be shown or clipped?  will the layout attempt to squeeze all three to fit the available space?

Can I get this answer from the javadoc?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829645476
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829654387
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829666593

From angorya at openjdk.org  Tue Nov  5 20:09:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:09:50 GMT
Subject: Integrated: 8342914: Remove calls to doPrivileged in swt
In-Reply-To: <lGGXH90dIw6klCyWnoxXnPjbVu7MkjtWC60SZQZp7Ww=.e0d67a5e-8162-4815-b4f4-9278e477b5bc@github.com>
References: <lGGXH90dIw6klCyWnoxXnPjbVu7MkjtWC60SZQZp7Ww=.e0d67a5e-8162-4815-b4f4-9278e477b5bc@github.com>
Message-ID: <BBdMZKUwM8qBvzhEPVHzMpFt8QDADrtoRgVFbiGjiS4=.cef4b636-116d-45ee-95b5-f215773728a7@github.com>

On Mon, 28 Oct 2024 14:52:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removes doPrivileged in the following module:
> 
> - javafx.swt
> 
> See JDK-8342441 for details.
> 
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide whitespace" option.

This pull request has now been integrated.

Changeset: bd4bc057
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bd4bc057b464e4cd0770474740652ba96887e455
Stats:     115 lines in 3 files changed: 15 ins; 68 del; 32 mod

8342914: Remove calls to doPrivileged in swt

Reviewed-by: kcr, jdv

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

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

From mstrauss at openjdk.org  Tue Nov  5 20:13:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 20:13:41 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <LYidT3o_FPDWXwb-Yxyu_-RciRyTLkYBHCfEyNK-5kw=.5f218fcd-c07a-439c-91c4-0e6d09e43272@github.com>

On Tue, 5 Nov 2024 16:34:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 118:
> 
>> 116: 
>> 117:     private static final String ALIGNMENT = "headerbar-alignment";
>> 118:     private static final String MARGIN = "headerbar-margin";
> 
> Q: should these be a String or an Object?  String.equals() are more expensive.
> 
> (I guess we use Strings elsewhere, so probably ok).

String literals are guaranteed to be interned by the [Java Language Specification](https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.10.5), so `equals()` is just a reference comparison.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829942979

From angorya at openjdk.org  Tue Nov  5 20:13:58 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:13:58 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v3]
In-Reply-To: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
Message-ID: <GSg4jj3pe1fOp1fxF4sSdJvqUerG7fi8g966SoPWyLg=.c86fbc93-8abf-4335-850a-d6c60460973b@github.com>

> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.

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:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342460.do.privileged.web
 - review comments
 - web

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1620/files
  - new: https://git.openjdk.org/jfx/pull/1620/files/1c1e8eab..dd44845e

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

  Stats: 1558 lines in 69 files changed: 96 ins; 889 del; 573 mod
  Patch: https://git.openjdk.org/jfx/pull/1620.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1620/head:pull/1620

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

From angorya at openjdk.org  Tue Nov  5 20:14:00 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:14:00 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v2]
In-Reply-To: <PhLOhoGkoqFJ-A9zEXPKxM9R1Vr61UfvqZBI6cv9pLI=.d5094175-cd47-48c9-b309-b458981de97c@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <I5fqsHM53MJFMOZXmHWmuQ10hrZuNx2AnhyAKPzmyKc=.e9b2103c-4bc3-491f-9477-1404d82dc776@github.com>
 <PhLOhoGkoqFJ-A9zEXPKxM9R1Vr61UfvqZBI6cv9pLI=.d5094175-cd47-48c9-b309-b458981de97c@github.com>
Message-ID: <Nc2BECO21p2lEPu2yMTeCWisSMsBJbMBO3ZD9sDWccc=.a634b99f-868a-42c4-9ee0-8821677349a7@github.com>

On Tue, 5 Nov 2024 06:45:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 1582:
> 
>> 1580:                         webEngine.debugger.messageCallback;
>> 1581:                 if (messageCallback != null) {
>> 1582:                     messageCallback.call(message);
> 
> @SuppressWarnings("removal") can be removed from this method.

removed, thanks!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1620#discussion_r1829942027

From angorya at openjdk.org  Tue Nov  5 20:17:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:17:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <LYidT3o_FPDWXwb-Yxyu_-RciRyTLkYBHCfEyNK-5kw=.5f218fcd-c07a-439c-91c4-0e6d09e43272@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <LYidT3o_FPDWXwb-Yxyu_-RciRyTLkYBHCfEyNK-5kw=.5f218fcd-c07a-439c-91c4-0e6d09e43272@github.com>
Message-ID: <-_1G4bMs1fAgCS1AJx1t1QTeVYgWpY5ZuwhnVFmBPJw=.d41e7ca7-bc9b-44d8-b0f0-25ee27c845dd@github.com>

On Tue, 5 Nov 2024 20:10:36 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 118:
>> 
>>> 116: 
>>> 117:     private static final String ALIGNMENT = "headerbar-alignment";
>>> 118:     private static final String MARGIN = "headerbar-margin";
>> 
>> Q: should these be a String or an Object?  String.equals() are more expensive.
>> 
>> (I guess we use Strings elsewhere, so probably ok).
>
> String literals are guaranteed to be interned by the [Java Language Specification](https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.10.5), so `equals()` is just a reference comparison.

good point.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829947138

From angorya at openjdk.org  Tue Nov  5 20:24:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:24:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
Message-ID: <D5TbsXA2L-WMQhYxJq6R_DEl6q2s-jm6aiZNSrAijts=.b118308f-4021-4687-988e-9f1afbb24aee@github.com>

On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is a new take on a highly requested feature: JavaFX controls in the header bar (see also #594 for an earlier iteration).
>> 
>> This is a feature with many possible ways to skin the cat, and it has taken quite a bit of effort to come up with a good user model. In contrast to the previous iteration, the focus has shifted from providing an entirely undecorated window to providing a window with a user-configurable header bar.
>> 
>> The customizable header bar is a new layout container: `javafx.scene.layout.HeaderBar`. It has three areas that accept child nodes: leading, center, and trailing.  `HeaderBar` also automatically adjusts for the placement of the default window buttons (minimize, maximize, close) on the left or right side of the window.
>> 
>> The customizable header bar is combined with a new `EXTENDED` stage style, which extends the client area into the header bar area. The new extended stage style is supported on Windows, macOS, and Linux. For platforms that don't support this stage style, it automatically downgrades to `DECORATED`.
>> 
>> This is how it looks like on each of the three operating systems:
>> 
>> ![extendedwindow](https://github.com/user-attachments/assets/9d798af6-09f4-4337-8210-6eae91079d3a)
>> 
>> The window buttons (minimize, maximize, close) are provided by JavaFX, not by the application developer. This makes it easier to get basic window functionality without recreating the entirety of the window controls for all platforms.
>> 
>> ## Usage
>> This is a minimal example that uses a custom header bar with a `TextField` in the center area. `HeaderBar` is usually placed in the top area of a `BorderPane` root container:
>> 
>> public class MyApp extends Application {
>>     @Override
>>     public void start(Stage stage) {
>>         var headerBar = new HeaderBar();
>>         headerBar.setCenter(new TextField());
>> 
>>         var root = new BorderPane();
>>         root.setTop(headerBar);
>> 
>>         stage.setScene(new Scene(root));
>>         stage.initStyle(StageStyle.EXTENDED);
>>         stage.show();
>>     }
>> }
>> 
>> To learn more about the details of the API, refer to the documentation of `StageStyle.EXTENDED` and `HeaderBar`.
>> 
>> ## Platform integration
>> The implementation varies per platform, and ranges from pretty easy to quite involved:
>> 1. **macOS**: The window buttons are provided by macOS, we just leave an empty area where the window buttons will appear. The client area is extended to cover the entire window by setting the `NSW...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stylistic changes

please link your JEP from this PR

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

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

From mstrauss at openjdk.org  Tue Nov  5 20:28:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 20:28:38 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <j_mIK0MsUzUte7sKK0EP_0uFyzdkcwwXDA540SGnspM=.6f4c22d3-f110-4a59-92ec-7966835e825b@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <Tk4e_cE4kedixu2kGpxOrZtc_ynJSqZwQfsoWanTsi0=.f1940035-f2ae-4fd8-89b2-9637da8d1833@github.com>
 <j_mIK0MsUzUte7sKK0EP_0uFyzdkcwwXDA540SGnspM=.6f4c22d3-f110-4a59-92ec-7966835e825b@github.com>
Message-ID: <w9enYTzzIz_1JPQXHDMzMC7hjOAn-5C7fXuy1hVBtDs=.c54fd39f-2f0b-47ba-bc7f-73634973ab0c@github.com>

On Tue, 5 Nov 2024 18:20:53 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Yeah, didn't work. In theory it should work with Wayland and a subsurface, like [libdecor](https://gitlab.freedesktop.org/libdecor/libdecor) does. X11 has the concept of multiple stacked Windows, in theory it's possible, I just don't know how to sync it.

I like the idea of having different subsurfaces for JavaFX client-side rendering and window decorations. We'd need a working Wayland backend, though...

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

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

From mstrauss at openjdk.org  Tue Nov  5 20:37:35 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 20:37:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <hEcFNQvYGOD7BzHZNzzSyv2fZ0XeFpvw5ZsRJ0-uye4=.05591fbf-ef1c-49fe-a3a4-149e8c0761f7@github.com>

On Tue, 5 Nov 2024 16:36:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 170:
> 
>> 168:         // Inflate the minHeight property. This is important so that we can track whether a stylesheet or
>> 169:         // user code changes the property value before we set it to the height of the native title bar.
>> 170:         minHeightProperty();
> 
> if that's the case, why not initialize it in L1150 ?

Where? The file only has about 500 lines.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829965296

From angorya at openjdk.org  Tue Nov  5 20:37:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 20:37:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <hEcFNQvYGOD7BzHZNzzSyv2fZ0XeFpvw5ZsRJ0-uye4=.05591fbf-ef1c-49fe-a3a4-149e8c0761f7@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <hEcFNQvYGOD7BzHZNzzSyv2fZ0XeFpvw5ZsRJ0-uye4=.05591fbf-ef1c-49fe-a3a4-149e8c0761f7@github.com>
Message-ID: <mHFQ-ht913NGqCcvLDrna0qtBS88aQWcZ-7Jf4XWgvw=.570befb7-e194-4ada-bb3b-409110b3d223@github.com>

On Tue, 5 Nov 2024 20:31:30 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 170:
>> 
>>> 168:         // Inflate the minHeight property. This is important so that we can track whether a stylesheet or
>>> 169:         // user code changes the property value before we set it to the height of the native title bar.
>>> 170:         minHeightProperty();
>> 
>> if that's the case, why not initialize it in L1150 ?
>
> Where? The file only has about 500 lines.

oops, my mistake.  It's in Region!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829968179

From johan.vos at gluonhq.com  Tue Nov  5 20:42:34 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 5 Nov 2024 21:42:34 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <CABxFH2GOmQ0bTmUQ9ykrbwQ-28P9HeJcwipUnokT5pGshcMCHg@mail.gmail.com>

Vote: YES

On Tue, Nov 5, 2024 at 4:02?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.
>
> Michael is an OpenJFX community member, who has contributed 41 commits
> [2] to OpenJFX. Michael regularly participates in code reviews,
> especially in the areas of JavaFX scene graph, graphics, and UI
> controls, offering valuable feedback.
>
> Votes are due by Nov 19, 2024 at 16:00 UTC.
>
> Only current OpenJFX Reviewers [3] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a
> project Reviewer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#mstrauss
>
> [2]
>
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits
> <https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau%C3%9F%22&type=commits>
>
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
>
> [5] https://openjdk.java.net/projects#project-reviewer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/fc58ab49/attachment.htm>

From mstrauss at openjdk.org  Tue Nov  5 20:43:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 20:43:38 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>

On Tue, 5 Nov 2024 16:47:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 51:
> 
>> 49:  * can specify draggable content nodes of the {@code HeaderBarBase} with the {@link #setDraggable} method.
>> 50:  *
>> 51:  * @apiNote Most application developers should use the {@link HeaderBar} implementation instead of
> 
> just curious: what's the reason to split the HB into the two classes?  Can you give an example?

The goal of the JEP is to allow fully customizable header bars (excluding window buttons). `HeaderBarBase` is the basic building block that is required for the headerbar-specific features like dragging, double clicking, and so on. This class is special because its functionality can't be replicated by user code.

For maximum customizability, `HeaderBarBase` is just a `Region`. Subclasses are free to implement any kind of control on top of that. This is what `HeaderBar` is: an implementation on top of the basic functionality, offering a pretty useful API and layout behavior. It covers many common use cases with the separation between a leading, center, and trailing area.

But special applications might have special requirements. For example, the Spotify desktop app selectively hides items in its header bar depending on the available space, and sometimes dynamically changes the alignment of items. This would be a case where an application would use a custom implementation of `HeaderBarBase`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829974615

From mstrauss at openjdk.org  Tue Nov  5 20:53:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 20:53:41 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <jAX2NVKw8M6rv5KFz1mAb5Zn1pn7GNkxC5IQ7E5j9ak=.efd5f323-94bf-47a6-8cb9-261e1f136d2a@github.com>

On Tue, 5 Nov 2024 19: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:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/resources/com/sun/glass/ui/gtk/WindowDecorationGnome.css line 26:
> 
>> 24:  */
>> 25: 
>> 26: .window-button-container {
> 
> is it possible for the app dev to alter the styling with an external style sheet?

No, that's not possible. This part of the implementation is a black box. It's also what makes the feature easy to use for app developers: they don't need to concern themselves with window decorations on the various supported platforms, they can rest assured that it will _just work_.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829984465

From angorya at openjdk.org  Tue Nov  5 21:05:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 21:05:37 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
Message-ID: <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>

On Tue, 5 Nov 2024 20:41:01 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 51:
>> 
>>> 49:  * can specify draggable content nodes of the {@code HeaderBarBase} with the {@link #setDraggable} method.
>>> 50:  *
>>> 51:  * @apiNote Most application developers should use the {@link HeaderBar} implementation instead of
>> 
>> just curious: what's the reason to split the HB into the two classes?  Can you give an example?
>
> The goal of the JEP is to allow fully customizable header bars (excluding window buttons). `HeaderBarBase` is the basic building block that is required for the headerbar-specific features like dragging, double clicking, and so on. This class is special because its functionality can't be replicated by user code.
> 
> For maximum customizability, `HeaderBarBase` is just a `Region`. Subclasses are free to implement any kind of control on top of that. This is what `HeaderBar` is: an implementation on top of the basic functionality, offering a pretty useful API and layout behavior. It covers many common use cases with the separation between a leading, center, and trailing area.
> 
> But special applications might have special requirements. For example, the Spotify desktop app selectively hides items in its header bar depending on the available space, and sometimes dynamically changes the alignment of items. This would be a case where an application would use a custom implementation of `HeaderBarBase`.

thanks for explanation.  but does it really warrant a base class, couldn't the app either set different components inside the existing HB, or maybe set a different HB?

is there anything that HeaderBar does that may not be needed in a custom title bar?

it just feels that HBBase is not needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829997063

From angorya at openjdk.org  Tue Nov  5 21:18:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 21:18:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v36]
In-Reply-To: <IzqFhWU1Owx_dMbA93D9O4zY18w-_6BV2AKV9j1NSBE=.1e27bec7-56a1-438b-bb59-a2d5248fbe05@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vd-oi9l8L4CE0jfbCu4VEJwY2iMWBEJqHnBgl2-TURM=.a4cf642a-91e2-4845-8510-7cc0ba1d320c@github.com>
 <IzqFhWU1Owx_dMbA93D9O4zY18w-_6BV2AKV9j1NSBE=.1e27bec7-56a1-438b-bb59-a2d5248fbe05@github.com>
Message-ID: <bdO4bk6Px5Iq32O4GIGvlFpZjwt--lFoj_Z6fsNBggw=.29e1e7f1-91b0-4bc2-98fc-1a9ce7bf830e@github.com>

On Tue, 5 Nov 2024 16:48:04 GMT, PavelTurk <duke at openjdk.org> wrote:

> the problem is that it doesn't support caret form

@PavelTurk there was a discussion re: caret with mixed text here
https://github.com/openjdk/jfx/pull/1220

This PR is closed now, but the issue (https://bugs.openjdk.org/browse/JDK-8296266) is still there and I hope to eventually resolve it.
Feel free to join the discussion (in the mailing list or the JBS ticket).

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2458165244

From mstrauss at openjdk.org  Tue Nov  5 21:19:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 21:19:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
Message-ID: <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>

On Tue, 5 Nov 2024 21:02:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The goal of the JEP is to allow fully customizable header bars (excluding window buttons). `HeaderBarBase` is the basic building block that is required for the headerbar-specific features like dragging, double clicking, and so on. This class is special because its functionality can't be replicated by user code.
>> 
>> For maximum customizability, `HeaderBarBase` is just a `Region`. Subclasses are free to implement any kind of control on top of that. This is what `HeaderBar` is: an implementation on top of the basic functionality, offering a pretty useful API and layout behavior. It covers many common use cases with the separation between a leading, center, and trailing area.
>> 
>> But special applications might have special requirements. For example, the Spotify desktop app selectively hides items in its header bar depending on the available space, and sometimes dynamically changes the alignment of items. This would be a case where an application would use a custom implementation of `HeaderBarBase`.
>
> thanks for explanation.  but does it really warrant a base class, couldn't the app either set different components inside the existing HB, or maybe set a different HB?
> 
> is there anything that HeaderBar does that may not be needed in a custom title bar?
> 
> it just feels that HBBase is not needed.

We need to think of this in terms of the user model. `HeaderBar` gives rise to three named areas (leading, center, trailing) and comes with a certain layout behavior for each of those areas.

Sure, it is possible to place another layout container in the `HeaderBar.center` area and set its prefWidth to infinity in order to effectively get rid of all of the custom layout behavior that `HeaderBar` brings to the table.

But that severely limits application and library developers from customizing the user model of the header bar. For example, using `HeaderBarBase`, a library developer can create alternative header bars with a different set of features and a different user model. Those alternative header bars might have different layout areas, different properties, in short a different API. It would be really awkward to shoehorn all of that into the (opinionated) API of `HeaderBar`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830013578

From angorya at openjdk.org  Tue Nov  5 21:24:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 21:24:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
 <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
Message-ID: <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>

On Tue, 5 Nov 2024 21:17:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> thanks for explanation.  but does it really warrant a base class, couldn't the app either set different components inside the existing HB, or maybe set a different HB?
>> 
>> is there anything that HeaderBar does that may not be needed in a custom title bar?
>> 
>> it just feels that HBBase is not needed.
>
> We need to think of this in terms of the user model. `HeaderBar` gives rise to three named areas (leading, center, trailing) and comes with a certain layout behavior for each of those areas.
> 
> Sure, it is possible to place another layout container in the `HeaderBar.center` area and set its prefWidth to infinity in order to effectively get rid of all of the custom layout behavior that `HeaderBar` brings to the table.
> 
> But that severely limits application and library developers from customizing the user model of the header bar. For example, using `HeaderBarBase`, a library developer can create alternative header bars with a different set of features and a different user model. Those alternative header bars might have different layout areas, different properties, in short a different API. It would be really awkward to shoehorn all of that into the (opinionated) API of `HeaderBar`.

I understand that, but could you give a **specific** example?

There is nothing in HB that prevents it from being used in all the scenarios I can think of.  It's like BorderPane - it can be used with a single center component, top and center, etc.  I just don't think we need a separate base class in this particular case, unless something in the HB **_prevents_** it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830019029

From andy.goryachev at oracle.com  Tue Nov  5 21:29:14 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 5 Nov 2024 21:29:14 +0000
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
Message-ID: <BL3PR10MB6185337784A85B24299D027DE5522@BL3PR10MB6185.namprd10.prod.outlook.com>

I think the incubator module is a great idea: it allows us to elicit feedback from the platform consumers (the actual target group) rather than a small subset of developers active on the mailing list, however great those people might be.  And being an incubator module, it allows us to send two clear signals:

- the proposed API and implementation are not final
- you, the developers, have a chance to have your voice heard and acted upon by the platform

I think it's a win-win for everyone involved.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Friday, November 1, 2024 at 15:18
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Proposal: JavaFX Incubator Modules
I'm restarting the discussion from an earlier thread [0], along with a
PR to get the support for JavaFX incubator modules integrated ahead of
any particular feature that might use them.

JEP 11 [1] defines a process for delivering non-final JDK APIs in
incubator modules.

Similarly, some JavaFX APIs would benefit from spending a period of time
in a JavaFX release prior to being deemed stable. I propose JavaFX
incubator modules as a means of putting non-final API in the hands of
developers, while the API progresses towards either finalization or
removal in a future release. This is especially useful for complex
features with a large API surface.

The JavaFX proposal is largely the same as the JDK one, but has some
important differences that are listed in the JEP.

Please take a look at the updated proposal [2] and PR 1616 [3] that adds
the needed support for incubator modules.

I have also created a Draft PR [4] with an example module, for
illustrative purposes only, to show how this might work. This Draft PR
is based on PR 1616.

Please reply to this message with any feedback, or add PR comments in PR
1616.

Thank you.

-- Kevin

[0] https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
[1] https://openjdk.org/jeps/11
[2]
https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
[4] https://github.com/openjdk/jfx/pull/1616
[5] https://github.com/openjdk/jfx/pull/1617
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241105/770a156c/attachment.htm>

From mstrauss at openjdk.org  Tue Nov  5 21:31:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 21:31:56 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v22]
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: <Je6WsW7wtat_sayZ_sZdYoo9_ZQUEPu6wlqWCqyi_CA=.ad7392f3-6427-470f-bdbd-6d54b293ae3c@github.com>

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

Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:

 - HeaderBar changes
 - EMPTY Dimension2D constant
 - use CsvSource in HeaderBarTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/d1c388bf..8974c141

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

  Stats: 142 lines in 3 files changed: 8 ins; 68 del; 66 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  Tue Nov  5 21:47:54 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 21:47:54 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - readme
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - review comments
 - input map
 - validate model
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - review comments
 - measurement node
 - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=36
  Stats: 39722 lines in 206 files changed: 39708 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From mstrauss at openjdk.org  Tue Nov  5 21:51:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 21:51:39 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <Dy_UvbPbr2T1ZSyYcMLQiqZ1GJ6ZKBYRtvs8JhOT_BI=.9ef5f3e3-b471-4e12-8925-b28a944b0ad0@github.com>

On Tue, 5 Nov 2024 16:37:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 262:
> 
>> 260:     @Override
>> 261:     protected double computeMinWidth(double height) {
>> 262:         Node leading = getLeading(), center = getCenter(), trailing = getTrailing();
> 
> I think it's a bad practice to have multiple statements on one line.

Changed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830045964

From mstrauss at openjdk.org  Tue Nov  5 21:51:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 21:51:39 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
 <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
 <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>
Message-ID: <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com>

On Tue, 5 Nov 2024 21:22:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> We need to think of this in terms of the user model. `HeaderBar` gives rise to three named areas (leading, center, trailing) and comes with a certain layout behavior for each of those areas.
>> 
>> Sure, it is possible to place another layout container in the `HeaderBar.center` area and set its prefWidth to infinity in order to effectively get rid of all of the custom layout behavior that `HeaderBar` brings to the table.
>> 
>> But that severely limits application and library developers from customizing the user model of the header bar. For example, using `HeaderBarBase`, a library developer can create alternative header bars with a different set of features and a different user model. Those alternative header bars might have different layout areas, different properties, in short a different API. It would be really awkward to shoehorn all of that into the (opinionated) API of `HeaderBar`.
>
> I understand that, but could you give a **specific** example?
> 
> There is nothing in HB that prevents it from being used in all the scenarios I can think of.  It's like BorderPane - it can be used with a single center component, top and center, etc.  I just don't think we need a separate base class in this particular case, unless something in the HB **_prevents_** it.

`BorderPane` is a good example. It's a customized API on top of `Pane`, which is basically just defined as a "collection of children":
> Base class for layout panes which need to expose the children list as public
> so that users of the subclass can freely add/remove children.

You're arguing that you wouldn't need `Pane` as a base class, because you can just as easily build a `VBox` on top of a `BorderPane` if you only use the center area and ignore all of the rest. While that's true, it's not a good user model.

I already gave you a specific example (Spotify) where an alternative implementation would dynamically change alignments, and presumably have a different API because of that.

As another example, take a look at what our WinUI friends are doing with their [TitleBar](https://github.com/microsoft/microsoft-ui-xaml/issues/9700). They have more API elements than our implementation (a back button, pane toggle button, icon, title, subtitle, and so on). The point of this example is _not_ to argue whether JavaFX developers could recreate this specific API by subclassing `HeaderBar`, it is to argue that custom APIs are relevant, and only `HeaderBarBase` gives developers a clean slate to create their own API.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830044746

From kcr at openjdk.org  Tue Nov  5 21:53:34 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 21:53:34 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v3]
In-Reply-To: <GSg4jj3pe1fOp1fxF4sSdJvqUerG7fi8g966SoPWyLg=.c86fbc93-8abf-4335-850a-d6c60460973b@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <GSg4jj3pe1fOp1fxF4sSdJvqUerG7fi8g966SoPWyLg=.c86fbc93-8abf-4335-850a-d6c60460973b@github.com>
Message-ID: <u7cQIo7VF3VlrI7W6C8MxepXIF41G4MUPOVosMrc6hw=.f5fcc7fc-3c1a-4b03-9767-a4a8fa26ca1e@github.com>

On Tue, 5 Nov 2024 20:13:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.
>
> 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:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342460.do.privileged.web
>  - review comments
>  - web

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1620#pullrequestreview-2416764554

From angorya at openjdk.org  Tue Nov  5 22:03:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 22:03:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
 <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
 <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>
 <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com>
Message-ID: <P0saYVBN4tWRmDfGI3ktJVFbO3iV4dwr7S6e5VJGAmg=.f93440c0-0516-43b1-bc11-f624948c07c5@github.com>

On Tue, 5 Nov 2024 21:48:04 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I understand that, but could you give a **specific** example?
>> 
>> There is nothing in HB that prevents it from being used in all the scenarios I can think of.  It's like BorderPane - it can be used with a single center component, top and center, etc.  I just don't think we need a separate base class in this particular case, unless something in the HB **_prevents_** it.
>
> `BorderPane` is a good example. It's a customized API on top of `Pane`, which is basically just defined as a "collection of children":
>> Base class for layout panes which need to expose the children list as public
>> so that users of the subclass can freely add/remove children.
> 
> You're arguing that you wouldn't need `Pane` as a base class, because you can just as easily build a `VBox` on top of a `BorderPane` if you only use the center area and ignore all of the rest. While that's true, it's not a good user model.
> 
> I already gave you a specific example (Spotify) where an alternative implementation would dynamically change alignments, and presumably have a different API because of that.
> 
> As another example, take a look at what our WinUI friends are doing with their [TitleBar](https://github.com/microsoft/microsoft-ui-xaml/issues/9700). They have more API elements than our implementation (a back button, pane toggle button, icon, title, subtitle, and so on). The point of this example is _not_ to argue whether JavaFX developers could recreate this specific API by subclassing `HeaderBar`, it is to argue that custom APIs are relevant, and only `HeaderBarBase` gives developers a clean slate to create their own API.

Perhaps I am not entirely clear.  But having these examples helped, thanks.

My point is that, in my opinion, we don't need two classes.  We only need one, with a single `'center'` property.  If the app needs leading/tailing/upper/lower/anythingElse, the app is free to use any container suitable for their need.

This way the platform provides the basis, which only the platform can provide.

So my suggestion would be to combine two classes into one with a single `'center'` property.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830057763

From angorya at openjdk.org  Tue Nov  5 22:41:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 22:41:35 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
In-Reply-To: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
Message-ID: <hTfvB2u68IOlFVPlpxJYceWIKHiQtUMfQB-XpfKzhR8=.0d645994-9076-4090-8ff9-bf40dccb4c3e@github.com>

On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
> 
> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
> 2. A utility class to produce warnings when first using an incubator module.
> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
> 
> See PR #1617 for a sample module that is built on top of this PR's source branch.
> 
> This is almost ready to review. I will take it out of Draft in the next day or so.

looks consistent with the original changes, but easier to understand.

had a few minor suggestions, will re-approve if you decide to fix it (WRAIYDTFI).

build.gradle line 2877:

> 2875: // Add a project declaration for each incubator module here, leaving the
> 2876: // incubator placeholder lines as an example.
> 2877: // BEGIN: incubator placeholder

Q: maybe we should mention the JBS every time we say the word "incubator"?

It might be useful to anyone who is looking at the code and has no access to git history (or when git history is obscured by a move).  I mean, JBS is our knowledge base, and it usually helps.

build.gradle line 4053:

> 4051:         //'incubator.mymod',
> 4052:         // END: incubator placeholder
> 4053: 

(same comment about empty lines)

settings.gradle line 42:

> 40:         "web",
> 41:         "media",
> 42:         "systemTests"

thank you for placing each entry on a separate line!

I would prefer to remove the blank lines around the comment so as not to break the visual grouping (the comments are typically syntax colored anyway unless the user is on TRS80)

settings.gradle line 53:

> 51: //project(":incubator.mymod").projectDir = file("modules/jfx.incubator.mymod")
> 52: // END: incubator placeholder
> 53: 

same suggestion about empty lines

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1616#pullrequestreview-2416811452
PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1830084515
PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1830080016
PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1830078671
PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1830079024

From mstrauss at openjdk.org  Tue Nov  5 22:42:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Nov 2024 22:42:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <P0saYVBN4tWRmDfGI3ktJVFbO3iV4dwr7S6e5VJGAmg=.f93440c0-0516-43b1-bc11-f624948c07c5@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
 <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
 <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>
 <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com>
 <P0saYVBN4tWRmDfGI3ktJVFbO3iV4dwr7S6e5VJGAmg=.f93440c0-0516-43b1-bc11-f624948c07c5@github.com>
Message-ID: <sHr7e7Wg8vF6MFl7_LG-KIO6U6wyq7PCw4TmCjUPKMM=.3f732c7d-2ad8-47fa-99d0-6f3589b2ef3d@github.com>

On Tue, 5 Nov 2024 22:01:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `BorderPane` is a good example. It's a customized API on top of `Pane`, which is basically just defined as a "collection of children":
>>> Base class for layout panes which need to expose the children list as public
>>> so that users of the subclass can freely add/remove children.
>> 
>> You're arguing that you wouldn't need `Pane` as a base class, because you can just as easily build a `VBox` on top of a `BorderPane` if you only use the center area and ignore all of the rest. While that's true, it's not a good user model.
>> 
>> I already gave you a specific example (Spotify) where an alternative implementation would dynamically change alignments, and presumably have a different API because of that.
>> 
>> As another example, take a look at what our WinUI friends are doing with their [TitleBar](https://github.com/microsoft/microsoft-ui-xaml/issues/9700). They have more API elements than our implementation (a back button, pane toggle button, icon, title, subtitle, and so on). The point of this example is _not_ to argue whether JavaFX developers could recreate this specific API by subclassing `HeaderBar`, it is to argue that custom APIs are relevant, and only `HeaderBarBase` gives developers a clean slate to create their own API.
>
> Perhaps I am not entirely clear.  But having these examples helped, thanks.
> 
> My point is that, in my opinion, we don't need two classes.  We only need one, with a single `'center'` property.  If the app needs leading/tailing/upper/lower/anythingElse, the app is free to use any container suitable for their need.
> 
> This way the platform provides the basis, which only the platform can provide.
> 
> So my suggestion would be to combine two classes into one with a single `'center'` property.
> 
> What do you think?

I see where you're coming from. While that might be a possible way to skin the cat, I think it has a few downsides. It would remove most API from `HeaderBar`, and instead, as you say, accept a single node as content. This would shift the concrete API from `HeaderBar` to whatever node/pane/layout container is placed in it.

However, the layout container inside this hypothetical header bar would, for many scenarios, need to have back-references to the header bar in order to achieve its purpose, either directly or indirectly by inspecting its own parents. One example is the centering behavior currently implemented for `HeaderBar.center` with a center-aligned node: it needs to know how wide the system insets are to compute the layout. This would mean that a layout container needs to be created that is aware of the context in which it is used, and changes its behavior (or maybe only meaningfully works) if it is placed in a `HeaderBar`.

So even recreating the current `HeaderBar` would lead to a bad and potentially fragile API. This, in my opinion, rules out the approach to shifting all layout behavior to a user-supplied layout container.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830093724

From jose.pereda at gluonhq.com  Tue Nov  5 22:44:27 2024
From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=)
Date: Tue, 5 Nov 2024 23:44:27 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <CABxFH2GOmQ0bTmUQ9ykrbwQ-28P9HeJcwipUnokT5pGshcMCHg@mail.gmail.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
 <CABxFH2GOmQ0bTmUQ9ykrbwQ-28P9HeJcwipUnokT5pGshcMCHg@mail.gmail.com>
Message-ID: <CAGMSBrJ0U6gp8PaQ+P3Geon5zqvery3j6_+2EwWkGS8rBZ7vbQ@mail.gmail.com>

Vote: YES

On Tue, Nov 5, 2024 at 9:43?PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Vote: YES
>
> On Tue, Nov 5, 2024 at 4:02?PM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.
>>
>> Michael is an OpenJFX community member, who has contributed 41 commits
>> [2] to OpenJFX. Michael regularly participates in code reviews,
>> especially in the areas of JavaFX scene graph, graphics, and UI
>> controls, offering valuable feedback.
>>
>> Votes are due by Nov 19, 2024 at 16:00 UTC.
>>
>> Only current OpenJFX Reviewers [3] are eligible to vote on this
>> nomination. Votes must be cast in the open by replying to this mailing
>> list.
>>
>> For Three-Vote Consensus voting instructions, see [4]. Nomination to a
>> project Reviewer is described in [5].
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>> [1] https://openjdk.org/census#mstrauss
>>
>> [2]
>>
>> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits
>> <https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau%C3%9F%22&type=commits>
>>
>> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits
>>
>> [3] https://openjdk.java.net/census#openjfx
>>
>> [4] https://openjdk.java.net/bylaws#three-vote-consensus
>>
>> [5] https://openjdk.java.net/projects#project-reviewer
>>
>>

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

From angorya at openjdk.org  Tue Nov  5 22:47:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 22:47:34 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <sHr7e7Wg8vF6MFl7_LG-KIO6U6wyq7PCw4TmCjUPKMM=.3f732c7d-2ad8-47fa-99d0-6f3589b2ef3d@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <EXiVLNDt7EIVbeNCcFEAJRGfCl4ah79t5fxTRyKK1xE=.838f0af2-c593-4265-a65d-8510d6548f33@github.com>
 <lp_A6E1kouBCjR5YtHaypdBeh_UU14Z7ZEvGVIA2A18=.92b70884-84bd-4499-9507-eb8a919c23a0@github.com>
 <wlKHQN9zEvrs9DQ9NypfHkV8wby7Hn4tpgKvj_Z99uY=.1a0d9c35-2172-4e88-89ab-28a0598e3262@github.com>
 <U4pNJQHKErrQUGt282EvxPOKL8hDJKPltLPcN-IoQZM=.5bb052ca-5f0f-4914-8c20-cca748f04cdb@github.com>
 <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com>
 <P0saYVBN4tWRmDfGI3ktJVFbO3iV4dwr7S6e5VJGAmg=.f93440c0-0516-43b1-bc11-f624948c07c5@github.com>
 <sHr7e7Wg8vF6MFl7_LG-KIO6U6wyq7PCw4TmCjUPKMM=.3f732c7d-2ad8-47fa-99d0-6f3589b2ef3d@github.com>
Message-ID: <cWvRbrsMFa51-PqSYXxknkcjOaWPRhZnLV9dpZAvkkc=.d2e40c9e-69f1-47a2-8882-b6ce31a0cae4@github.com>

On Tue, 5 Nov 2024 22:39:57 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Perhaps I am not entirely clear.  But having these examples helped, thanks.
>> 
>> My point is that, in my opinion, we don't need two classes.  We only need one, with a single `'center'` property.  If the app needs leading/tailing/upper/lower/anythingElse, the app is free to use any container suitable for their need.
>> 
>> This way the platform provides the basis, which only the platform can provide.
>> 
>> So my suggestion would be to combine two classes into one with a single `'center'` property.
>> 
>> What do you think?
>
> I see where you're coming from. While that might be a possible way to skin the cat, I think it has a few downsides. It would remove most API from `HeaderBar`, and instead, as you say, accept a single node as content. This would shift the concrete API from `HeaderBar` to whatever node/pane/layout container is placed in it.
> 
> However, the layout container inside this hypothetical header bar would, for many scenarios, need to have back-references to the header bar in order to achieve its purpose, either directly or indirectly by inspecting its own parents. One example is the centering behavior currently implemented for `HeaderBar.center` with a center-aligned node: it needs to know how wide the system insets are to compute the layout. This would mean that a layout container needs to be created that is aware of the context in which it is used, and changes its behavior (or maybe only meaningfully works) if it is placed in a `HeaderBar`.
> 
> So even recreating the current `HeaderBar` would lead to a bad and potentially fragile API. This, in my opinion, rules out the approach to shifting all layout behavior to a user-supplied layout container.

aha!  this is the (good) argument I was asking for, thanks!

I mean, I am not buying it entirely, since "centering" may mean different things to different people - for example using window half-width may or may not be a good centering position if you have asymmetry due to the buttons on one side, perhaps it would be better to center across the empty area instead.

But if other people are ok with breaking up this thing into two classes, I won't object (much).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830098487

From philip.race at oracle.com  Tue Nov  5 23:02:25 2024
From: philip.race at oracle.com (Philip Race)
Date: Tue, 5 Nov 2024 15:02:25 -0800
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <8ddd0468-2d1a-4fb6-998f-fe8d603994a3@oracle.com>

Vote: yes

-phil.


From angorya at openjdk.org  Tue Nov  5 23:03:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Nov 2024 23:03:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v22]
In-Reply-To: <Je6WsW7wtat_sayZ_sZdYoo9_ZQUEPu6wlqWCqyi_CA=.ad7392f3-6427-470f-bdbd-6d54b293ae3c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <Je6WsW7wtat_sayZ_sZdYoo9_ZQUEPu6wlqWCqyi_CA=.ad7392f3-6427-470f-bdbd-6d54b293ae3c@github.com>
Message-ID: <RgIxKWTrtiTR_S_2aLbu24Y_9Rbg4I82CAwi_5NLFKQ=.99108c47-d446-43b0-a2b9-2f6e591f2898@github.com>

On Tue, 5 Nov 2024 21:31:56 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - HeaderBar changes
>  - EMPTY Dimension2D constant
>  - use CsvSource in HeaderBarTest

modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HeaderBarTest.java line 237:

> 235:         "BOTTOM_RIGHT, 740, 40, 100, 50"
> 236:     })
> 237:     void alignmentOfCenterChild_notResizable_withNonEmptyLeadingAndTrailingChild(

minor suggestion:

long test names do not help much (and actually may cause problems, see https://bugs.openjdk.org/browse/JDK-8334497)

also rather inconvenient to see in the logs, or IDEs.  You can use comments for human-readability and short(er) method names.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1830157870

From john.hendrikx at gmail.com  Tue Nov  5 23:33:21 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 6 Nov 2024 00:33:21 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <1faffd61-9f5a-4495-9ca9-9bcc28afd2f0@gmail.com>

Vote: YES

On 05/11/2024 16:01, Kevin Rushforth wrote:
> I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.
>
> Michael is an OpenJFX community member, who has contributed 41 commits 
> [2] to OpenJFX. Michael regularly participates in code reviews, 
> especially in the areas of JavaFX scene graph, graphics, and UI 
> controls, offering valuable feedback.
>
> Votes are due by Nov 19, 2024 at 16:00 UTC.
>
> Only current OpenJFX Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a 
> project Reviewer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#mstrauss
>
> [2]
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits 
>
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits 
>
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
>
> [5] https://openjdk.java.net/projects#project-reviewer
>

From kcr at openjdk.org  Tue Nov  5 23:49:04 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 23:49:04 GMT
Subject: [jfx23u] RFR: 8342917: GHA: Intermittent build failure on Linux while
 downloading ant
Message-ID: <nSPhKW-esF2brI9J6Xb1xL5sIZhG_Ph8uviLBLj_hjU=.fc5abdde-11f8-436f-8157-2c589ab4de2e@github.com>

Effectively clean backport of the GHA fix on Linux to install ant using the package manager. I couldn't use the Skara backport command because of differences in the surrounding context. The diffs themselves are identical to the mainline patch.

As with the mainline patch, this will help avoid noise in GHA builds on Linux.

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

Commit messages:
 - 8342917: GHA: Intermittent build failure on Linux while downloading ant

Changes: https://git.openjdk.org/jfx23u/pull/28/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=28&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342917
  Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx23u/pull/28.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/28/head:pull/28

PR: https://git.openjdk.org/jfx23u/pull/28

From kcr at openjdk.org  Tue Nov  5 23:49:04 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Nov 2024 23:49:04 GMT
Subject: [jfx23u] RFR: 8342917: GHA: Intermittent build failure on Linux
 while downloading ant
In-Reply-To: <nSPhKW-esF2brI9J6Xb1xL5sIZhG_Ph8uviLBLj_hjU=.fc5abdde-11f8-436f-8157-2c589ab4de2e@github.com>
References: <nSPhKW-esF2brI9J6Xb1xL5sIZhG_Ph8uviLBLj_hjU=.fc5abdde-11f8-436f-8157-2c589ab4de2e@github.com>
Message-ID: <LZvrE3PXK4e3NSgmFf8D42GXahZPvS0b2iUphofKsNA=.dc7b0f8d-385c-47bf-b4d5-6e9dad1299fe@github.com>

On Tue, 5 Nov 2024 23:41:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Effectively clean backport of the GHA fix on Linux to install ant using the package manager. I couldn't use the Skara backport command because of differences in the surrounding context. The diffs themselves are identical to the mainline patch.
> 
> As with the mainline patch, this will help avoid noise in GHA builds on Linux.

@johanvos I request maintainer approval at your convenience.

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

PR Comment: https://git.openjdk.org/jfx23u/pull/28#issuecomment-2458422404

From angorya at openjdk.org  Wed Nov  6 00:00:32 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 00:00:32 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
Message-ID: <6EAnJy3hsegHLzJafQ_ss-A3gqM40PkK6GQKt_d4SVM=.00f6b668-cd33-4b55-a4f8-c4a61161ba26@github.com>

On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.
> 
> As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:
> 
> 1. It will minimize the changes to native WebKit JNI code.
> 2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.
> 
> This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).
> 
> NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

looks good.

the only suggestion I have is maybe leave comments pointing to the JBS which will help anyone years later to decipher what this thing is and why it is passed along and not used.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1626#pullrequestreview-2417007557

From arapte at openjdk.org  Wed Nov  6 02:45:36 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 6 Nov 2024 02:45:36 GMT
Subject: RFR: 8342460: Remove calls to doPrivileged in javafx.web [v3]
In-Reply-To: <GSg4jj3pe1fOp1fxF4sSdJvqUerG7fi8g966SoPWyLg=.c86fbc93-8abf-4335-850a-d6c60460973b@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
 <GSg4jj3pe1fOp1fxF4sSdJvqUerG7fi8g966SoPWyLg=.c86fbc93-8abf-4335-850a-d6c60460973b@github.com>
Message-ID: <MqVdUFT7zmFjE6ujEHptdNbmnmUBOVBHSkQq_omgtRc=.3ddf9210-eec7-4a5d-bb9c-b287525c3057@github.com>

On Tue, 5 Nov 2024 20:13:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.
>
> 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:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342460.do.privileged.web
>  - review comments
>  - web

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1620#pullrequestreview-2417141694

From arapte at openjdk.org  Wed Nov  6 03:39:09 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 6 Nov 2024 03:39:09 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base [v2]
In-Reply-To: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
Message-ID: <EQzLIbO96kcSPh0BUAJz0tIiew4fDU2OF6dq1CDHLGY=.7fd70667-a943-4a87-aee9-a47bbc35872b@github.com>

> Remove `doPrivileged` calls in the javafx.base module.
> The changes are straight forward.
> 1. Remove doPrivileged calls, with keeping the lambda expression.
> 2. Remove SuppressWarnings annotations
> 3. Remove unused imports

Ambarish Rapte 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:

 - review: rm unused acc
 - Merge branch 'master' into rm-doPrivi
 - rm doPrivileged in javafx.base

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1625/files
  - new: https://git.openjdk.org/jfx/pull/1625/files/2405da91..70ebdf94

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

  Stats: 213 lines in 18 files changed: 18 ins; 152 del; 43 mod
  Patch: https://git.openjdk.org/jfx/pull/1625.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1625/head:pull/1625

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

From arapte at openjdk.org  Wed Nov  6 03:45:36 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 6 Nov 2024 03:45:36 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base [v2]
In-Reply-To: <sB3pIabGawj_r2z2AhLTK36e2744xqxwmx_8GSoWQzk=.15f9e5b5-c6ad-4df1-9545-b63bb1e2d49f@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
 <sB3pIabGawj_r2z2AhLTK36e2744xqxwmx_8GSoWQzk=.15f9e5b5-c6ad-4df1-9545-b63bb1e2d49f@github.com>
Message-ID: <p5mRfFQrzYXrw9favXDsxDcu5VkE3dg87XEC61OIASw=.ebf6df5b-5aa9-4f89-899a-b64689e01d69@github.com>

On Tue, 5 Nov 2024 18:51:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte 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:
>> 
>>  - review: rm unused acc
>>  - Merge branch 'master' into rm-doPrivi
>>  - rm doPrivileged in javafx.base
>
> modules/javafx.base/src/main/java/javafx/beans/property/adapter/JavaBeanBooleanProperty.java line 42:
> 
>> 40: import java.security.AccessControlContext;
>> 41: import java.security.AccessController;
>> 42: import java.security.PrivilegedAction;
> 
> I think you can remove the now-unused field `private final AccessControlContext acc`, which will also let you remove the `AccessControlContext` and  `AccessController`. Alternatively, I will remove them as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> This comment applies to all of the `JavaBeanXXXProperty` classes.

Thanks Kevin, The variable `acc` and related 2 imports are now removed in [commit](https://github.com/openjdk/jfx/pull/1625/commits/70ebdf944e6b31b731dc2be93ddda78e0402d700).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1625#discussion_r1830349887

From jdv at openjdk.org  Wed Nov  6 05:13:48 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 6 Nov 2024 05:13:48 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
Message-ID: <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>

> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
> 
> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
> 
> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1624/files
  - new: https://git.openjdk.org/jfx/pull/1624/files/ae7add4c..d00dcdba

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

  Stats: 19 lines in 3 files changed: 0 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1624.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1624/head:pull/1624

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

From jdv at openjdk.org  Wed Nov  6 05:13:48 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 6 Nov 2024 05:13:48 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <EQJSDXvaab9wzmEOcG-6n6MOdBB0XFDbUm1XkJou_XM=.95f2a020-635a-460b-93db-864b4562cc94@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>
 <EQJSDXvaab9wzmEOcG-6n6MOdBB0XFDbUm1XkJou_XM=.95f2a020-635a-460b-93db-864b4562cc94@github.com>
Message-ID: <1rMQYYNPI9zJ1er4Sb0WDi6fOaeEmT5xI8grfUw9fO4=.09dd9970-c7b4-4aad-ae71-02530d5cae31@github.com>

On Tue, 5 Nov 2024 14:39:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Accessible.java line 169:
>> 
>>> 167:             getAttribute.attribute = attribute;
>>> 168:             getAttribute.parameters = parameters;
>>> 169:             return getAttribute;
>> 
>> This needs to be `getAttribute.get()` to be equivalent to the previous code.
>
> Alternatively, the following would work and be simpler, if you prefer:
> 
> 
>     public Object getAttribute(AccessibleAttribute attribute, Object... parameters) {
>         getAttribute.attribute = attribute;
>         getAttribute.parameters = parameters;
>         return QuantumToolkit.runWithoutRenderLock(getAttribute);
>     }

Thanks for noticing this Kevin. This was root cause for ClassCastException seen when running HelloTextArea with VoiceOver enabled. I have verified that with updated code we don't see any exceptions.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1830397551

From john.hendrikx at gmail.com  Wed Nov  6 09:38:15 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 6 Nov 2024 10:38:15 +0100
Subject: RichTextArea and InputMap incubator modules [was: Proposal:
 JavaFX Incubator Modules]
In-Reply-To: <316c9c47-0450-4424-bd6b-9466232e6a57@oracle.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <CAJEpuXQF-bHwpWQ7_9MMiOkd5mV07H6kMoseMUUKNMJUDg3_kQ@mail.gmail.com>
 <316c9c47-0450-4424-bd6b-9466232e6a57@oracle.com>
Message-ID: <fdc14039-bd58-4e9c-aceb-d917c8c8fb80@gmail.com>

It's a bit odd though to move forward with a proposal that had no clear 
consensus with developers on design and technical grounds first before 
getting community feedback.? I have not seen this with any of the other 
JEP's published.??Community feedback on this will need heavy filtering, 
as with other JEP's, there will be plenty of uninformed opinions.? 
However I cannot imagine such?feedback being useful on the level of API 
design when the developers here already see several?big design flaws. It 
would be much more prudent to first iron those out before presenting 
something that the developers here, who actually know the framework 
better than most, already feel is an inadequate design.

So to me, yes, this still is simply trying a different route to get a 
proposal through that was already deemed to need more design before it 
can be accepted.? Now however this proposal once presented as an 
incubator feature will be pushed with uninformed and short-sighted 
opinions that "just want a RichText control" completely ignoring 
the?tag-along InputMap part. One only needs to look in the bug tracker 
or StackOverflow to see many of such opinions where there is a lack of 
understanding of basic FX features, which are then used to justify some 
new API or feature demand.

I also feel like it is ridiculous to tie a new **Control** to a new API, 
as if it would be impossible to achieve otherwise.? Any PR that exceeds 
its scope in such fashion would normally be rejected, and told to be 
split into multiple parts.

PR's should be kept small and focused to make them realistically 
reviewable, being an incubator IMHO does not free you from passing 
review.? That means these must be broken up in pieces that can be 
understood and reasoned about (like what happened to the Preferences API 
for example).? The RichText PR? from what I can see it is making 
sweeping changes in many areas unrelated to a new Control, and 
with?40.000 lines, is one of the largest PR's ever. Such large PR's are 
only acceptable if they are limited in scope, or are doing only fully 
compatible changes (ie. clean ups, or refactoring of internals).

--John

On 05/11/2024 00:07, Kevin Rushforth wrote:
> As noted, the current RichTextArea proposal depends on the InputMap 
> proposal. Andy will make this more clear by filing a new JBS 
> Enhancement (or reusing the existing one) for "InputMap (Incubator)", 
> and adding that issue to the RichTextArea PR.
>
> The idea of incubating InputMap along with RichTextArea is to get 
> feedback on InputMap as an incubating feature with a concrete example 
> control that uses it, and would benefit by it. An alternative would 
> have been to incubate InputMap separately, although that would require 
> picking a simple control or two and creating a "test" version of that 
> control solely for the purpose of testing InputMap. I don't think it 
> would provide the kind of feedback we are looking for. Using it with a 
> control that we actually expect developers to use seems like a better 
> test of InputMap. It does tie the two proposals together, at least 
> during the time that they are incubating.
>
> Given that RTA and InputMap are two distinct features, I can see three 
> likely outcomes after incubating for some number of releases, where we 
> gain feedback and iterate the design and API:
>
> 1. Both RTA and InputMap gain general acceptance among app developers 
> -- in this case, both would be finalized at the same time in some 
> future release. This is what we are aiming for.
> 2. RTA gains general acceptance, but InputMap does not -- in this 
> case, RTA would need to be reworked to remove all dependencies on 
> InputMap, with some alternate customization of behavior that is 
> specific to RTA, which would then be finalized in some future release.
> 3. Neither RTA nor InputMap gain general acceptance -- in this case, 
> both would be removed in some future release.
>
> -- Kevin
>
>
> On 11/1/2024 4:19 PM, Michael Strau? wrote:
>> I think it should be made clear that incubation is not an alternative
>> to, or a path around community concensus. Specifically, I'm looking at
>> the RichTextArea proposal, which seems to also incubate the InputMap
>> proposal. If we accepted the incubation of incidental features without
>> community concensus, then surely at some point in the future, we'd be
>> discussing that we now must commit to a controversial incidental
>> feature because the momentum is too strong, or because we'd be
>> breaking code of too many users that are already using the new
>> features. Any discussion around promoting the main incubating feature
>> to API, and dropping incidental features will be tainted with
>> real-world usage arguments.
>

From ajit.ghaisas at oracle.com  Wed Nov  6 09:51:03 2024
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 6 Nov 2024 09:51:03 +0000
Subject: =?utf-8?B?UmU6IENGVjogTmV3IE9wZW5KRlggUmV2aWV3ZXI6IE1pY2hhZWwgU3RyYXU=?=
 =?utf-8?B?w58=?=
In-Reply-To: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
References: <c74c0d1d-f720-46ef-a009-247f6c592278@oracle.com>
Message-ID: <D12A055C-42B4-4000-9AB4-1C827DA2ED4C@oracle.com>

Vote: YES

Regards,
Ajit

> On 5 Nov 2024, at 8:31?PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I hereby nominate Michael Strau? [1] to OpenJFX Reviewer.
> 
> Michael is an OpenJFX community member, who has contributed 41 commits [2] to OpenJFX. Michael regularly participates in code reviews, especially in the areas of JavaFX scene graph, graphics, and UI controls, offering valuable feedback.
> 
> Votes are due by Nov 19, 2024 at 16:00 UTC.
> 
> Only current OpenJFX Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a project Reviewer is described in [5].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.org/census#mstrauss
> 
> [2]
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Michael+Strau?%22&type=commits
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22mstr2%22&type=commits
> 
> [3] https://openjdk.java.net/census#openjfx
> 
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
> 
> [5] https://openjdk.java.net/projects#project-reviewer
> 


From jcorvel at gmail.com  Wed Nov  6 10:58:43 2024
From: jcorvel at gmail.com (Johan Corveleyn)
Date: Wed, 6 Nov 2024 11:58:43 +0100
Subject: Integrated: 8340982: [win] Dead key followed by Space generates
 two characters instead of one
In-Reply-To: <CAK7C+XgS1Reo1hGWbpw=uE-DsSAZqCbBNnAv77Y+3WogLDgDuQ@mail.gmail.com>
References: <PyljFPympx4RWe_rxfGQt1cx8FDg-Vwp-vzIbprOe54=.2d8f387e-5b55-4b9c-92ae-5f4995a7aae3@github.com>
 <AJ-GDGQM5PpeJ3rJWwqnf5celujc0dBJcVxxn6tdApw=.360a16d5-e6f8-46c6-8374-0f158e717c70@github.com>
 <CAB84uBUN6Lianhw0RjznXaztr3dy1P0ZM-OwKWCZd=U7MQsxKA@mail.gmail.com>
 <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com>
 <CAB84uBVOnFw4_pcwsioKmw-pBbQJRHQW3Wqstoxa+GGe7aj04Q@mail.gmail.com>
 <CAB84uBVQGGY4SA1Nzs0ZHW7gcHPHJ1OX00YtVygz=EiaaOvVsw@mail.gmail.com>
 <CAB84uBV_=vNyryinYEVZAW7bgZfo8vvQezCMiaL1kjEo66eS=w@mail.gmail.com>
 <CAK7C+XgS1Reo1hGWbpw=uE-DsSAZqCbBNnAv77Y+3WogLDgDuQ@mail.gmail.com>
Message-ID: <CAB84uBVG1wcCnKVC9_O9fWxxmKsZH9gTjfO5_4h9x+Wy9yw6FA@mail.gmail.com>

Hi Johan,

Thanks for explaining. I've taken a look at that JEP 14 document, and
I can certainly understand the reasoning behind it.

And indeed, this is a P4 bug, not particularly critical. Though the
fix is small and low-risk, it is still a change and it inevitably
takes resources to backport (always more than expected, I know :-)).
Depending on how strict the "backport as little as possible" rule is
interpreted, this may or may not be taken along.

I don't have anything particular to throw into the balance, so I'll
just see where this goes. In any case, thanks for considering /
discussing it, and for having taken the time for your thoughful
response.

-- 
Johan C

On Tue, Nov 5, 2024 at 11:59?AM Johan Vos <johan at lodgon.com> wrote:
>
> Hi Johan,
>
> Sorry for not replying earlier.
> Since this is a real small fix, I think it makes sense to backport it to 17/21.
> I'm a bit hesitant because of JEP 14 [1] and the current discussions on the Tip&Tail approach [2] , where it is explicitly discouraged to backport anything apart from vulnerabilities and critical errors. Since this is a P4 bug, I don't think it qualifies -- hence my doubt.
>
> This is a situation that I believe could be discussed in jdk-dev -- not for this issue in particular, but rather the principle: what is the recommendation with backport requests for P4 bugs that are "small" and "guaranteed to have no regression"?
>
> I don't think it's good to have the discussion at 2 places, but to summarize some of the key reasons on why not backporting non-criticial things:
> * we do not want to break existing work in LTS releases (software that relies on some undocumented internal JavaFX behavior might go wrong if the behavior is changed)
> * we need to make sure the CPU fixes can "easily" be backported.
> * time spent in tail-backporting can not be spent in tip-development. And unfortunately, I learned the hard way that backporting is much more time-consuming (and error-prone) than I hoped for.
>
> Having said that, I definitely don't want to reject this upfront -- just want to clarify the complexity and I very much welcome other input.
>
> - Johan
>
> [1]  https://openjdk.org/jeps/14
> [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009433.html
>
>
> Op di 5 nov 2024 om 11:40 schreef Johan Corveleyn <jcorvel at gmail.com>:
>>
>> On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn <jcorvel at gmail.com> wrote:
>> >
>> > On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn <jcorvel at gmail.com> wrote:
>> > >
>> > > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth
>> > > <kevin.rushforth at oracle.com> wrote:
>> > > >
>> > > > Gluon maintains JavaFX 17 and 21, so Johan can answer that.
>> > > >
>> > > > There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK.
>> > >
>> > > Ah yes, for 8 we use the Oracle JDK which includes its JavaFX build.
>> > > So for backport to Oracle Java 8 I guess we'd need to ask Oracle.
>> > >
>> > > Having this fix backported into OpenJFX 17 and 21 would be great though.
>> >
>> > Coming back to this: any chance this fix could be backported to
>> > OpenJFX 17 and 21?
>>
>> One last try: anyone able to backport this deadkey fix to 17 and 21?
>> Or even take it into consideration for inclusion in OpenJFX 11 or JDK
>> 8?
>>
>> --
>> Johan

From jdv at openjdk.org  Wed Nov  6 11:04:45 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 6 Nov 2024 11:04:45 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v15]
In-Reply-To: <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>
Message-ID: <cJRo38tG58tKap_cJVN4B42GHrI7udeQILPOvzpsBHw=.c4ee71f7-77bf-4359-9d8f-bd10fa4ea451@github.com>

On Sat, 2 Nov 2024 05:02:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert doc change

Went through the files again and latest change LGTM apart from the suggestion about package name for JDK ImageIO usage.

Tested loading svg images also using sample app.

modules/javafx.graphics/src/test/addExports line 22:

> 20: --add-exports javafx.graphics/com.sun.javafx.iio=ALL-UNNAMED
> 21: --add-exports javafx.graphics/com.sun.javafx.iio.png=ALL-UNNAMED
> 22: --add-exports javafx.graphics/com.sun.javafx.iio.javax=ALL-UNNAMED

I am little bit hesitant about this package name. Using "javax" doesn't give clear idea what we are trying to do here.

May be com.sun.javafx.iio.imageio is a better option.

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

Marked as reviewed by jdv (Author).

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2417866140
PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1830768433

From kcr at openjdk.org  Wed Nov  6 12:09:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 12:09:33 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
Message-ID: <NkShQnGQChKFZi22DblLHFeo1LoEw9jVIEx700-ZIXE=.330acd65-27ab-4b71-9ae1-a8899a50280c@github.com>

On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review comments

Looks good. I also verified that a11y now works.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2418093893

From kcr at openjdk.org  Wed Nov  6 12:12:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 12:12:35 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base [v2]
In-Reply-To: <EQzLIbO96kcSPh0BUAJz0tIiew4fDU2OF6dq1CDHLGY=.7fd70667-a943-4a87-aee9-a47bbc35872b@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
 <EQzLIbO96kcSPh0BUAJz0tIiew4fDU2OF6dq1CDHLGY=.7fd70667-a943-4a87-aee9-a47bbc35872b@github.com>
Message-ID: <X3_LF6E4S5ZfSqPvk7sMUV80buGvynmq32jdCSB5FzE=.696ae3c3-5b42-40f8-9a1f-468e70093b38@github.com>

On Wed, 6 Nov 2024 03:39:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Remove `doPrivileged` calls in the javafx.base module.
>> The changes are straight forward.
>> 1. Remove doPrivileged calls, with keeping the lambda expression.
>> 2. Remove SuppressWarnings annotations
>> 3. Remove unused imports
>
> Ambarish Rapte 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:
> 
>  - review: rm unused acc
>  - Merge branch 'master' into rm-doPrivi
>  - rm doPrivileged in javafx.base

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1625#pullrequestreview-2418102868

From kcr at openjdk.org  Wed Nov  6 12:17:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 12:17:39 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <6EAnJy3hsegHLzJafQ_ss-A3gqM40PkK6GQKt_d4SVM=.00f6b668-cd33-4b55-a4f8-c4a61161ba26@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
 <6EAnJy3hsegHLzJafQ_ss-A3gqM40PkK6GQKt_d4SVM=.00f6b668-cd33-4b55-a4f8-c4a61161ba26@github.com>
Message-ID: <9k_Ar2Siq3gvZkxaaa2oakbuspxvIFAJcgMDZPBaSfI=.e01a61a1-7d98-4e14-9206-200118d718e5@github.com>

On Tue, 5 Nov 2024 23:58:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> the only suggestion I have is maybe leave comments pointing to the JBS which will help anyone years later to decipher what this thing is and why it is passed along and not used.

Good idea. I will leave a comment as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) when I remove the remaining references to `AccessControlContext`. I don't like the practice of leaving pointers to JBS bug IDs that have been fixed, but will explain why the parameter still exists.

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

PR Comment: https://git.openjdk.org/jfx/pull/1626#issuecomment-2459595005

From nlisker at gmail.com  Wed Nov  6 12:57:47 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 6 Nov 2024 14:57:47 +0200
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <BL3PR10MB6185337784A85B24299D027DE5522@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <BL3PR10MB6185337784A85B24299D027DE5522@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh9wrFVEpgOsz99rJVWYPpf6A3-HRxRph+B8cdED9-wOZQ@mail.gmail.com>

Being able to add an API without the guarantee for backwards compatibility
(temporarily) is obviously alleviating to the developers and will ensure a
better end result. My only concern is the amount of usability this can get.
Incubating modules usually offer a substantial amount of code. In the JDK
there are only a handful of incubating modules, like FFM and Vector API.
JavaFX hardly has these huge changes. RTA is perhaps the first one and it
seems like incubating modules in JavaFX are added ad-hoc for that. What
other uses are envisioned as an incubating module?
Are various platform-related changes like platform preferences,
customizable window headers etc. suitable for an incubating module? The
Metal/DX12 pipelines? One of the many CSS proposals? Behavior/Skin/Input
splitting proposals? From what I know, an incubating module is suitable for
independent features that can be "nailed on the side" for a while until
they are seamlessly integrated, but I don't see JavaFX having many of those.

On Wed, Nov 6, 2024 at 12:22?AM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> I think the incubator module is a great idea: it allows us to elicit
> feedback from the platform consumers (the actual target group) rather than
> a small subset of developers active on the mailing list, however great
> those people might be.  And being an incubator module, it allows us to send
> two clear signals:
>
>
>
> - the proposed API and implementation are not final
>
> - you, the developers, have a chance to have your voice heard and acted
> upon by the platform
>
>
>
> I think it's a win-win for everyone involved.
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Friday, November 1, 2024 at 15:18
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Re: Proposal: JavaFX Incubator Modules
>
> I'm restarting the discussion from an earlier thread [0], along with a
> PR to get the support for JavaFX incubator modules integrated ahead of
> any particular feature that might use them.
>
> JEP 11 [1] defines a process for delivering non-final JDK APIs in
> incubator modules.
>
> Similarly, some JavaFX APIs would benefit from spending a period of time
> in a JavaFX release prior to being deemed stable. I propose JavaFX
> incubator modules as a means of putting non-final API in the hands of
> developers, while the API progresses towards either finalization or
> removal in a future release. This is especially useful for complex
> features with a large API surface.
>
> The JavaFX proposal is largely the same as the JDK one, but has some
> important differences that are listed in the JEP.
>
> Please take a look at the updated proposal [2] and PR 1616 [3] that adds
> the needed support for incubator modules.
>
> I have also created a Draft PR [4] with an example module, for
> illustrative purposes only, to show how this might work. This Draft PR
> is based on PR 1616.
>
> Please reply to this message with any feedback, or add PR comments in PR
> 1616.
>
> Thank you.
>
> -- Kevin
>
> [0]
> https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
> [1] https://openjdk.org/jeps/11
> [2]
>
> https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
> [4] https://github.com/openjdk/jfx/pull/1616
> [5] https://github.com/openjdk/jfx/pull/1617
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241106/e8fd698f/attachment.htm>

From lkostyra at openjdk.org  Wed Nov  6 13:42:32 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 6 Nov 2024 13:42:32 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
Message-ID: <nwQzqWvpWbHjFgHQsjQFscymP6sPrz_4C2gq3qWASj0=.4eb82dbc-e905-44f8-864b-ae5a2d5847b9@github.com>

On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review comments

LGTM, although there are some changes I cannot verify (notably iOS) and would be good to have someone check on those before merging

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

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2418306947

From johan.vos at gluonhq.com  Wed Nov  6 13:57:16 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 6 Nov 2024 14:57:16 +0100
Subject: Proposal: JavaFX Incubator Modules
In-Reply-To: <CA+0ynh9wrFVEpgOsz99rJVWYPpf6A3-HRxRph+B8cdED9-wOZQ@mail.gmail.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <BL3PR10MB6185337784A85B24299D027DE5522@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh9wrFVEpgOsz99rJVWYPpf6A3-HRxRph+B8cdED9-wOZQ@mail.gmail.com>
Message-ID: <CABxFH2Fqi_r7Xm+y3YYbUUu492Ar4ZWw5=HE-b6NYNVtsGW6mg@mail.gmail.com>

Thank you Kevin for restarting the discussion!

Adding to what others said (very valid feedback from Michael/John), I
specifically want to add a comment about Nir's remark where he mentioned
Metal/DX12 pipelines.
I am a bit worried about the difference between the openjfx sandbox
repository and the incubating modules. There are currently (at least) 4
very important branches in the sandbox, that imho are much more important
than adding more functionality in the controls (which can be added in
userspace):
* Metal pipeline
* Wayland pipeline
* Direct3D12 pipeline
* Headless glass platform

Those projects do not add new functionality, but they are crucial for
maintaining OpenJFX. They are the foundation of existing and new features.
They are less visible to end-developers, as they don't change/add external
API's. That combination (being critical for OpenJFX and not being
attractive to get tested because it's not new functionality) is a bit
dangerous, so I believe we must give this high priority, make sure they get
reviewed in the OpenJFX community and tested outside the OpenJFX community.

At least with a number of incubating modules in OpenJDK, there was initial
sandbox development, which really allows for testing/feedback. If we allow
incubating modules to skip this sandbox stage, then I'm not sure there is
more value left in the sandbox repository.

- Johan

On Wed, Nov 6, 2024 at 1:59?PM Nir Lisker <nlisker at gmail.com> wrote:

> Being able to add an API without the guarantee for backwards compatibility
> (temporarily) is obviously alleviating to the developers and will ensure a
> better end result. My only concern is the amount of usability this can get.
> Incubating modules usually offer a substantial amount of code. In the JDK
> there are only a handful of incubating modules, like FFM and Vector API.
> JavaFX hardly has these huge changes. RTA is perhaps the first one and it
> seems like incubating modules in JavaFX are added ad-hoc for that. What
> other uses are envisioned as an incubating module?
> Are various platform-related changes like platform preferences,
> customizable window headers etc. suitable for an incubating module? The
> Metal/DX12 pipelines? One of the many CSS proposals? Behavior/Skin/Input
> splitting proposals? From what I know, an incubating module is suitable for
> independent features that can be "nailed on the side" for a while until
> they are seamlessly integrated, but I don't see JavaFX having many of those.
>
> On Wed, Nov 6, 2024 at 12:22?AM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
>> I think the incubator module is a great idea: it allows us to elicit
>> feedback from the platform consumers (the actual target group) rather than
>> a small subset of developers active on the mailing list, however great
>> those people might be.  And being an incubator module, it allows us to send
>> two clear signals:
>>
>>
>>
>> - the proposed API and implementation are not final
>>
>> - you, the developers, have a chance to have your voice heard and acted
>> upon by the platform
>>
>>
>>
>> I think it's a win-win for everyone involved.
>>
>>
>>
>> -andy
>>
>>
>>
>>
>>
>>
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
>> Rushforth <kevin.rushforth at oracle.com>
>> *Date: *Friday, November 1, 2024 at 15:18
>> *To: *openjfx-dev <openjfx-dev at openjdk.org>
>> *Subject: *Re: Proposal: JavaFX Incubator Modules
>>
>> I'm restarting the discussion from an earlier thread [0], along with a
>> PR to get the support for JavaFX incubator modules integrated ahead of
>> any particular feature that might use them.
>>
>> JEP 11 [1] defines a process for delivering non-final JDK APIs in
>> incubator modules.
>>
>> Similarly, some JavaFX APIs would benefit from spending a period of time
>> in a JavaFX release prior to being deemed stable. I propose JavaFX
>> incubator modules as a means of putting non-final API in the hands of
>> developers, while the API progresses towards either finalization or
>> removal in a future release. This is especially useful for complex
>> features with a large API surface.
>>
>> The JavaFX proposal is largely the same as the JDK one, but has some
>> important differences that are listed in the JEP.
>>
>> Please take a look at the updated proposal [2] and PR 1616 [3] that adds
>> the needed support for incubator modules.
>>
>> I have also created a Draft PR [4] with an example module, for
>> illustrative purposes only, to show how this might work. This Draft PR
>> is based on PR 1616.
>>
>> Please reply to this message with any feedback, or add PR comments in PR
>> 1616.
>>
>> Thank you.
>>
>> -- Kevin
>>
>> [0]
>> https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
>> [1] https://openjdk.org/jeps/11
>> [2]
>>
>> https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
>> [4] https://github.com/openjdk/jfx/pull/1616
>> [5] https://github.com/openjdk/jfx/pull/1617
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241106/c2cf0683/attachment.htm>

From arapte at openjdk.org  Wed Nov  6 14:05:47 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 6 Nov 2024 14:05:47 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
Message-ID: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>

On Tue, 5 Nov 2024 21:47:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits:
> 
>  - readme
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - review comments
>  - input map
>  - validate model
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - javadoc
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - review comments
>  - measurement node
>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151

Providing a few comments. I shall continue to review.

modules/jfx.incubator.input/README.md line 4:

> 2: 
> 3: This project incubates
> 4: [InputMap](src/main/java/javafx/incubator/scene/control/rich/RichTextArea.java)

The link seems to be incorrect.

modules/jfx.incubator.input/README.md line 6:

> 4: [InputMap](src/main/java/javafx/incubator/scene/control/rich/RichTextArea.java)
> 5: 
> 6: Please refer to this [README](/tests/manual/RichTextAreaDemo/README.md).

May be a pointer to exact sample which uses the new InputMap classes would be good here.

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/EventHandlerPriority.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright year correction, may be it should be done as the last item before final push. (just in case if the PR reaches year 2025)

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/KeyEventMapper.java line 39:

> 37:     private static final int TYPED = 0x04;
> 38: 
> 39:     private int types;

I think, the 3 event types are mutually exclusive, either a key would be pressed or released or typed.
so the name of this variable should be a singular form `type` or preferably `eventType`

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/KeyEventMapper.java line 42:

> 40: 
> 41:     public KeyEventMapper() {
> 42:     }

May be remove empty default ctor.

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 46:

> 44:      * [ USER_HIGH, handler1, handler2, SKIN_KB, SKIN_LOW, handler3 ]
> 45:      */
> 46:     private final ArrayList<Object> items = new ArrayList(4);

Is there any specific reason as to why initial size is 4 ?  Could use a final constant instead.

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 49:

> 47: 
> 48:     public PHList() {
> 49:     }

Can remove empty ctor.

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 53:

> 51:     @Override
> 52:     public String toString() {
> 53:         return "PHList" + items;

`return "PHList:" + items;`  ->  `return "PHList{items=" + items + "}";`

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 72:

> 70:             if (handler != null) {
> 71:                 insert(++ix, handler);
> 72:             }

Is it necessary to store the priority when the handler is `null`. 
Will it be safe to simply return at beginning of the method when `handler == null` ?

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 74:

> 72:             }
> 73:         } else {
> 74:             insert(ix, handler);

Is `if (handler != null)` check required here as well?

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 88:

> 86:     /**
> 87:      * Removes all the instances of the specified handler.  Returns true if the list becomes empty as a result.
> 88:      * Returns true if the list becomes empty as a result of the removal.

`Returns true if the list becomes empty as a result` :-> This comment is repeated on line 87 and 88. It can be removed from line 87.

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 106:

> 104:             }
> 105:         }
> 106:         return items.size() == 0;

Use of  `ArrayList.isEmpty()`  would look nicer.
`return items.size() == 0;`  -> `return items.isEmpty();`

modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 213:

> 211:             }
> 212:         }
> 213:         return items.size() == 0;

Use of ArrayList.isEmpty() would look nicer.
return items.size() == 0; -> return items.isEmpty();

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 69:

> 67:         CTRL,
> 68:         /** META modifier, mapped to COMMAND on Mac, META on Windows/Linux */
> 69:         META,

The Command key on mac is mapped to both COMMAND(Line#65) and META.
Is there a difference of right and left Command key ? If Yes, then may be it could be specified in the comment here.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 97:

> 95: 
> 96:     /**
> 97:      * Utility method creates a KeyBinding corresponding to a key press.

Minor: typo / rewording. Similar comment applies to other helper methods of this class.
`Utility method creates`  -> `Utility method that creates`  OR  `Utility method to create`

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 257:

> 255:      */
> 256:     public boolean isCommand() {
> 257:         return modifiers.contains(KCondition.COMMAND);

Could safe guard with `if (PlatformUtil.isMac())` check to `return false` if not a mac platform

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 274:

> 272:      */
> 273:     public boolean isOption() {
> 274:         return modifiers.contains(KCondition.OPTION);

Could safe guard with `if (PlatformUtil.isMac())` check to `return false` if not a mac platform

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 708:

> 706:             } else if (linux) {
> 707:                 replace(KCondition.SHORTCUT, KCondition.CTRL);
> 708:             }

the two else blocks can be combined into one.

else if (win || linux) {
    replace(KCondition.SHORTCUT, KCondition.CTRL);
}

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 715:

> 713:                 } else if (m.contains(KCondition.OPTION)) {
> 714:                     return null;
> 715:                 }

if else can be combined into a single if statement.

if (m.contains(KCondition.COMMAND) || m.contains(KCondition.OPTION)) {
    return null;
}

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

PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2417914541
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830794361
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830796450
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830799862
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830829104
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830829802
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830898100
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830894968
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831039599
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831043789
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831046085
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830902022
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830920903
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831069876
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830843738
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830871042
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830874251
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830875391
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830890067
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1830892125

From lkostyra at openjdk.org  Wed Nov  6 14:33:36 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 6 Nov 2024 14:33:36 GMT
Subject: RFR: 8342459: Remove calls to doPrivileged in javafx.base [v2]
In-Reply-To: <EQzLIbO96kcSPh0BUAJz0tIiew4fDU2OF6dq1CDHLGY=.7fd70667-a943-4a87-aee9-a47bbc35872b@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
 <EQzLIbO96kcSPh0BUAJz0tIiew4fDU2OF6dq1CDHLGY=.7fd70667-a943-4a87-aee9-a47bbc35872b@github.com>
Message-ID: <L0gtUVJd0kewGZkb6dJhzn7GETAO79LEgJp44xoLdZA=.647589a1-3e4c-407e-aaa2-cc9ba4fa5382@github.com>

On Wed, 6 Nov 2024 03:39:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Remove `doPrivileged` calls in the javafx.base module.
>> The changes are straight forward.
>> 1. Remove doPrivileged calls, with keeping the lambda expression.
>> 2. Remove SuppressWarnings annotations
>> 3. Remove unused imports
>
> Ambarish Rapte 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:
> 
>  - review: rm unused acc
>  - Merge branch 'master' into rm-doPrivi
>  - rm doPrivileged in javafx.base

Marked as reviewed by lkostyra (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1625#pullrequestreview-2418441941

From kcr at openjdk.org  Wed Nov  6 15:20:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 15:20:47 GMT
Subject: [jfx23u] Integrated: 8342917: GHA: Intermittent build failure on Linux
 while downloading ant
In-Reply-To: <nSPhKW-esF2brI9J6Xb1xL5sIZhG_Ph8uviLBLj_hjU=.fc5abdde-11f8-436f-8157-2c589ab4de2e@github.com>
References: <nSPhKW-esF2brI9J6Xb1xL5sIZhG_Ph8uviLBLj_hjU=.fc5abdde-11f8-436f-8157-2c589ab4de2e@github.com>
Message-ID: <Gy-nA2CFLAcesfuHPqon9SDhIvpUSO8-q-eefHhGg20=.b4f4252b-c4ca-44d4-b3fb-534e4f0bb3fe@github.com>

On Tue, 5 Nov 2024 23:41:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Effectively clean backport of the GHA fix on Linux to install ant using the package manager. I couldn't use the Skara backport command because of differences in the surrounding context. The diffs themselves are identical to the mainline patch.
> 
> As with the mainline patch, this will help avoid noise in GHA builds on Linux.

This pull request has now been integrated.

Changeset: 454cff39
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/454cff391c21afb5f712ded4df0580847651e4f1
Stats:     14 lines in 1 file changed: 3 ins; 0 del; 11 mod

8342917: GHA: Intermittent build failure on Linux while downloading ant

Backport-of: caf078acd42fabc3d9746471b54a77f3b86ff305

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

PR: https://git.openjdk.org/jfx23u/pull/28

From arapte at openjdk.org  Wed Nov  6 15:22:35 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 6 Nov 2024 15:22:35 GMT
Subject: Integrated: 8342459: Remove calls to doPrivileged in javafx.base
In-Reply-To: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
References: <AcUCCYfbYhw6DtwG4Aly_JtWFd0VH5JT5_PN_bPT0Gc=.f443e10b-0a69-4356-a5d6-a4bccf8e805d@github.com>
Message-ID: <_lpYQqb32nGa8tgXp8CzFgD1wEswKjFbxBcWrW9adFA=.636cede4-6457-4a25-bdab-527b7f484d45@github.com>

On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Remove `doPrivileged` calls in the javafx.base module.
> The changes are straight forward.
> 1. Remove doPrivileged calls, with keeping the lambda expression.
> 2. Remove SuppressWarnings annotations
> 3. Remove unused imports

This pull request has now been integrated.

Changeset: 71c6b16c
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/71c6b16c2fed266bb69ffd778294811f8c6a507c
Stats:     460 lines in 20 files changed: 17 ins; 243 del; 200 mod

8342459: Remove calls to doPrivileged in javafx.base

Reviewed-by: kcr, lkostyra

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

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

From angorya at openjdk.org  Wed Nov  6 15:36:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 15:36:36 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <9k_Ar2Siq3gvZkxaaa2oakbuspxvIFAJcgMDZPBaSfI=.e01a61a1-7d98-4e14-9206-200118d718e5@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
 <6EAnJy3hsegHLzJafQ_ss-A3gqM40PkK6GQKt_d4SVM=.00f6b668-cd33-4b55-a4f8-c4a61161ba26@github.com>
 <9k_Ar2Siq3gvZkxaaa2oakbuspxvIFAJcgMDZPBaSfI=.e01a61a1-7d98-4e14-9206-200118d718e5@github.com>
Message-ID: <E-g3rmOqk1aJ7lIL5-QFlTwnk5LlYdCZv5x8MOFdcNQ=.c60a53ee-9ad0-4470-94fa-923a1a1a50c3@github.com>

On Wed, 6 Nov 2024 12:15:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I don't like the practice of leaving pointers to JBS bug IDs that have been fixed

We don't have a well-defined knowledge base with permanent links which would have been better.  The use of JBS ids, even resolved ones, might be the next best thing because these ids are:

- more or less permanent (except for RT-...)
- are easily grep'pable
- point to a place that has description of the problem and the link to PR and maybe some discussion
- directly observable (as opposed to git commit history)
- cannot be masked by refactoring or merge (unlike git commit history)

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

PR Comment: https://git.openjdk.org/jfx/pull/1626#issuecomment-2460088659

From kcr at openjdk.org  Wed Nov  6 15:42:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 15:42:37 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
Message-ID: <Fsx1cuZKicnCMQ9EpN_gGsXb4Hz9PIkKg4JbPXbFtLM=.40d23dbc-4f34-4f9f-84a8-b9e7c6a00aaf@github.com>

On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review comments

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Accessible.java line 186:

> 184:             executeAction.action = action;
> 185:             executeAction.parameters = parameters;
> 186:             return executeAction;

I just noticed that this has the same problem that `getAttribute` had, which I reported and you fixed. The return value isn't used (so we didn't get a fail fast), but I'm pretty sure that this will cause a problem in that `executeAction` will never be executed.

For consistency, you might consider changing it in the same way as you did for `getAttribute`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1831260172

From angorya at openjdk.org  Wed Nov  6 15:45:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 15:45:43 GMT
Subject: Integrated: 8342460: Remove calls to doPrivileged in javafx.web
In-Reply-To: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com>
Message-ID: <zUqu8-bQfx363US3yj0idXfghE5lxrKfvTlpmGmkADM=.654cd838-d6af-4992-9148-0f373aed2d16@github.com>

On Thu, 31 Oct 2024 22:51:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removes `doPrivileged` calls in the javafx.web module, excluding the code in `{android,ios}`.

This pull request has now been integrated.

Changeset: 3d15a306
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3d15a3065c272d79011f99f77c1bdd0d8801e290
Stats:     330 lines in 17 files changed: 13 ins; 214 del; 103 mod

8342460: Remove calls to doPrivileged in javafx.web

Reviewed-by: kcr, arapte

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

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

From kevin.rushforth at oracle.com  Wed Nov  6 16:16:36 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 6 Nov 2024 08:16:36 -0800
Subject: [External] : Re: Proposal: JavaFX Incubator Modules
In-Reply-To: <CABxFH2Fqi_r7Xm+y3YYbUUu492Ar4ZWw5=HE-b6NYNVtsGW6mg@mail.gmail.com>
References: <BL3PR10MB618504707480A4958E261D0CE5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB618531D714D764F574D48BA9E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ad3d46b6-d982-4d44-9386-59acd7057123@oracle.com>
 <BL3PR10MB618579DA043A059F41039252E5502@BL3PR10MB6185.namprd10.prod.outlook.com>
 <BL3PR10MB61851D0A5923995642B17738E5572@BL3PR10MB6185.namprd10.prod.outlook.com>
 <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com>
 <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com>
 <BL3PR10MB6185337784A85B24299D027DE5522@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh9wrFVEpgOsz99rJVWYPpf6A3-HRxRph+B8cdED9-wOZQ@mail.gmail.com>
 <CABxFH2Fqi_r7Xm+y3YYbUUu492Ar4ZWw5=HE-b6NYNVtsGW6mg@mail.gmail.com>
Message-ID: <b0d24884-fee5-4af7-abc6-89e7607345fb@oracle.com>

As I see it, there are three different, but at least somewhat 
overlapping, ways to get non-final functionality into the hands of 
developers for testing:

1. Experimental EA test build from a sandbox branch -- a parallel build, 
distinct from jfx mainline builds

A sandbox branch (which is equivalent to a project repo like loom, 
lanai, or valhalla without having to create a separate repo), is a way 
to do all sorts of experiments. When additional feedback is needed, 
producing an experimental EA test build can be a way to have developers 
"kick the tires" to see how well it works. This is suitable for things 
that impact the implementation, like a new graphics pipeline? (Metal, 
D3D12), a new glass backend (wayland, headless), or some other idea. 
Such a test build might have limitations, might not be functionally 
complete, some things might not work, etc. It could also be used to test 
drive a new API before it is ready for a wider test. A sandbox build 
could be suitable for things where the goal is to have a few motivated 
developers test a specific feature, since they will need to be willing 
to go grab a custom experimental build and use it.

2. Incubator modules -- API in incubator.* modules in the jfx mainline 
builds

This is API that isn't ready to be finalized and is subject to change, 
but is ready to be in the mainline with the same level of quality as 
anything else that goes into the mainline, meaning it needs to be 
functionally complete, and not break anything else. It is in a separate 
module so an application knows that are using incubating APIs. The APIs 
are likely to change in response to feedback.

3. Preview features -- API in standard modules in the jfx mainline builds

This is APIthat is almost ready to finalize. It would typically be in an 
existing module as new packages, new classes in existing packages, or 
new methods in existing classes. The API is subject to change, but might 
not change if there are no concerns raised. Since we don't have compiler 
and runtime support, we will need some other "opt in" mechanism so that 
an application knows they are using preview features. Michael proposed 
preview features [1] and I think it's worth revisiting that proposal.

All three have their uses. And while some features might go from sandbox 
--> incubator or sandbox --> preview, it isn't a hard requirement in the 
JDK, and shouldn't be a hard requirement for JavaFX. Some things will go 
directly to mainline without any experimental phase (that's been the 
case for all new JavaFX features up to this point). Some might go into a 
sandbox test build and then into mainline, like Metal (there is no API, 
so incubator modules or preview features are not suitable), some might 
go to incubator then mainline, while other might go to preview and then 
mainline.

We might want to start a new thread on Preview features and experimental 
sandbox builds, although we can discuss the aspects that are common to 
all three in this thread.

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1359


On 11/6/2024 5:57 AM, Johan Vos wrote:
> Thank you Kevin for restarting the discussion!
>
> Adding to what others said (very valid feedback from Michael/John), I 
> specifically want to add a comment about Nir's remark where he 
> mentioned Metal/DX12 pipelines.
> I am a bit worried about the difference between the openjfx sandbox 
> repository and the incubating modules. There are currently (at least) 
> 4 very important branches in the sandbox, that imho are much more 
> important than adding more functionality in the controls (which can be 
> added in userspace):
> * Metal pipeline
> * Wayland pipeline
> * Direct3D12 pipeline
> * Headless glass platform
>
> Those projects do not add new functionality, but they are crucial for 
> maintaining OpenJFX. They are the foundation of existing and new 
> features. They are less visible to end-developers, as they don't 
> change/add external API's. That combination (being critical for 
> OpenJFX and not being attractive to get tested because it's not new 
> functionality) is a bit dangerous, so I believe we must give this high 
> priority, make sure they get reviewed in the OpenJFX community and 
> tested outside the OpenJFX community.
>
> At least with a number of incubating modules in OpenJDK, there was 
> initial sandbox development, which really allows for testing/feedback. 
> If we allow incubating modules to skip this sandbox stage, then I'm 
> not sure there is more value left in the sandbox repository.
>
> - Johan
>
> On Wed, Nov 6, 2024 at 1:59?PM Nir Lisker <nlisker at gmail.com> wrote:
>
>     Being able to add an API without the guarantee for backwards
>     compatibility (temporarily) is obviously alleviating?to the
>     developers and will ensure a better end result. My only concern is
>     the amount of usability this can get. Incubating modules usually
>     offer a substantial amount of code. In the JDK there are only a
>     handful of incubating modules, like FFM and Vector API. JavaFX
>     hardly has these huge?changes. RTA is perhaps the first one and it
>     seems like incubating modules in JavaFX are added ad-hoc for that.
>     What other uses are envisioned as an incubating module?
>     Are various platform-related changes like platform preferences,
>     customizable window headers etc. suitable for an incubating
>     module? The Metal/DX12 pipelines? One of the many CSS proposals?
>     Behavior/Skin/Input splitting proposals? From what I know, an
>     incubating module is suitable for independent features?that can be
>     "nailed on the side" for a while until they are seamlessly
>     integrated, but I don't see JavaFX having many of those.
>
>     On Wed, Nov 6, 2024 at 12:22?AM Andy Goryachev
>     <andy.goryachev at oracle.com> wrote:
>
>         I think the incubator module is a great idea: it allows us to
>         elicit feedback from the platform consumers (the actual target
>         group) rather than a small subset of developers active on the
>         mailing list, however great those people might be.? And being
>         an incubator module, it allows us to send two clear signals:
>
>         - the proposed API and implementation are not final
>
>         - you, the developers, have a chance to have your voice heard
>         and acted upon by the platform
>
>         I think it's a win-win for everyone involved.
>
>         -andy
>
>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf
>         of Kevin Rushforth <kevin.rushforth at oracle.com>
>         *Date: *Friday, November 1, 2024 at 15:18
>         *To: *openjfx-dev <openjfx-dev at openjdk.org>
>         *Subject: *Re: Proposal: JavaFX Incubator Modules
>
>         I'm restarting the discussion from an earlier thread [0],
>         along with a
>         PR to get the support for JavaFX incubator modules integrated
>         ahead of
>         any particular feature that might use them.
>
>         JEP 11 [1] defines a process for delivering non-final JDK APIs in
>         incubator modules.
>
>         Similarly, some JavaFX APIs would benefit from spending a
>         period of time
>         in a JavaFX release prior to being deemed stable. I propose
>         JavaFX
>         incubator modules as a means of putting non-final API in the
>         hands of
>         developers, while the API progresses towards either
>         finalization or
>         removal in a future release. This is especially useful for
>         complex
>         features with a large API surface.
>
>         The JavaFX proposal is largely the same as the JDK one, but
>         has some
>         important differences that are listed in the JEP.
>
>         Please take a look at the updated proposal [2] and PR 1616 [3]
>         that adds
>         the needed support for incubator modules.
>
>         I have also created a Draft PR [4] with an example module, for
>         illustrative purposes only, to show how this might work. This
>         Draft PR
>         is based on PR 1616.
>
>         Please reply to this message with any feedback, or add PR
>         comments in PR
>         1616.
>
>         Thank you.
>
>         -- Kevin
>
>         [0]
>         https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045508.html
>         [1] https://openjdk.org/jeps/11
>         [2]
>         https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md
>         <https://urldefense.com/v3/__https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOY5NZPqw$>
>         [4] https://github.com/openjdk/jfx/pull/1616
>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1616__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEOKbjtAUg$>
>         [5] https://github.com/openjdk/jfx/pull/1617
>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1617__;!!ACWV5N9M2RV99hQ!OxkvtfwPGuYvKPf38hg3CqUvHaoJplhg3-MFh1uMmazAfhqNjP2YXbb_Ttx3Ax6KPpk2l_8TRs4os2ipTEO6j7QKaw$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241106/af7784d0/attachment-0001.htm>

From angorya at openjdk.org  Wed Nov  6 17:43:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 17:43:40 GMT
Subject: Withdrawn: 8090456: Focus Management
In-Reply-To: <bo8lZjmAWyAdsX7ixhxQ2og_U4z0UeDrPpBR7xzsH9M=.8e5f63a7-662b-4a00-97d4-6a9e44ed7580@github.com>
References: <bo8lZjmAWyAdsX7ixhxQ2og_U4z0UeDrPpBR7xzsH9M=.8e5f63a7-662b-4a00-97d4-6a9e44ed7580@github.com>
Message-ID: <MiPoAR1HsOSjIm98IMOzLj0fUSDpDdVbzWxhqfDLBd8=.c1501a4e-e299-4fb2-a9ed-d582dc13178a@github.com>

On Tue, 3 Sep 2024 19:09:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Public APIs for focus traversal and the focus traversal policy:
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md
> 
> This work is loosely based on the patch
> https://cr.openjdk.org/~jgiles/8061673/

This pull request has been closed without being integrated.

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

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

From angorya at openjdk.org  Wed Nov  6 17:53:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 17:53:41 GMT
Subject: Withdrawn: 8091673: Public focus traversal API for use in custom
 controls (with the traversal policy hidden)
In-Reply-To: <-sr392G05uYl-tZeOWxQV1GRDHj2KgWqMg1jv45irag=.ce8a7983-994a-4a7a-8df6-d13eecd1b47c@github.com>
References: <-sr392G05uYl-tZeOWxQV1GRDHj2KgWqMg1jv45irag=.ce8a7983-994a-4a7a-8df6-d13eecd1b47c@github.com>
Message-ID: <yr5JPhm5O5HhTIbvJL2fERF71WmmBN0487IYF4O-u_Q=.387812ec-2028-4907-84ac-d77e30712d73@github.com>

On Fri, 18 Oct 2024 19:20:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Public focus traversal API for use in custom controls
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This work is loosely based on the patch
> https://cr.openjdk.org/~jgiles/8061673/
> 
> And is a scaled down version (with the public traversal policy API removed) of
> #1555

This pull request has been closed without being integrated.

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

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

From angorya at openjdk.org  Wed Nov  6 17:53:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 17:53:40 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls (with the traversal policy hidden) [v9]
In-Reply-To: <HbyArjqd0ZnGxt_bMufDqU07_yYkeQNMG-PeyORNK4M=.79adaf62-c76b-4867-b755-e3612923ecf2@github.com>
References: <-sr392G05uYl-tZeOWxQV1GRDHj2KgWqMg1jv45irag=.ce8a7983-994a-4a7a-8df6-d13eecd1b47c@github.com>
 <HbyArjqd0ZnGxt_bMufDqU07_yYkeQNMG-PeyORNK4M=.79adaf62-c76b-4867-b755-e3612923ecf2@github.com>
Message-ID: <DUHAqb5hwzX0TqkxpONACEhIghtGCQvT3dtwjRdzwF8=.1ac35d2e-f88f-45c9-8511-5d78634555f5@github.com>

On Thu, 31 Oct 2024 14:58:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This work is loosely based on the patch
>> https://cr.openjdk.org/~jgiles/8061673/
>> 
>> And is a scaled down version (with the public traversal policy API removed) of
>> #1555
>
> 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 15 additional commits since the last revision:
> 
>  - newline
>  - Merge remote-tracking branch 'origin/master' into 8091673.focus.traversal.2
>  - the
>  - review comments
>  - visible
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8091673.focus.traversal.2
>  - review comments
>  - review comments
>  - request focus traversal
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/d1777e48...b82c37d4

Closing in favor of #1628.

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

PR Comment: https://git.openjdk.org/jfx/pull/1604#issuecomment-2460420099

From angorya at openjdk.org  Wed Nov  6 18:08:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 18:08:02 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom controls
Message-ID: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>

Public focus traversal API for use in custom controls.

https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md

This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

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

Commit messages:
 - request focus traversal

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

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

From mstrauss at openjdk.org  Wed Nov  6 18:39:54 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 18:39:54 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v23]
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: <rlrG5hF9_fA9MMCGHYTcXx-NZ0664nKy1nOncf-AVYU=.994f8864-d8be-4039-8bc1-a9b4e588ea31@github.com>

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

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

  refactor performWindowDrag

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/8974c141..ca9b325a

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

  Stats: 18 lines in 3 files changed: 9 ins; 8 del; 1 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  Wed Nov  6 18:39:55 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 18:39:55 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <Am7k7pl5vBPowBhci9IjmY79pl8u5wF7yxwZmGO1eHk=.31feaef9-3ca6-4ba5-b1c7-6b2b20d1258c@github.com>

On Tue, 5 Nov 2024 19:03:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1336:
> 
>> 1334: }
>> 1335: 
>> 1336: - (NSEvent*)lastEvent
> 
> could there be side effects with exposing this field?
> concurrency issues?

The native toolkits are single-threaded. Anyway, I chose to refactor this a bit, removing the exposed `lastEvent` field and instead providing the method `performWindowDrag` that is called instead. The logic to supply the `lastEvent` is now contained in `GlassViewDelegate`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831533708

From mstrauss at openjdk.org  Wed Nov  6 18:44:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 18:44:36 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <D5TbsXA2L-WMQhYxJq6R_DEl6q2s-jm6aiZNSrAijts=.b118308f-4021-4687-988e-9f1afbb24aee@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <D5TbsXA2L-WMQhYxJq6R_DEl6q2s-jm6aiZNSrAijts=.b118308f-4021-4687-988e-9f1afbb24aee@github.com>
Message-ID: <sROExJQFDg6ep3o9nfrcVyKZiFDrhSnDU_43Vb-MWLo=.90eb4e34-a9d9-48a1-b80d-aceb3cd6ea51@github.com>

On Tue, 5 Nov 2024 20:22:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> please link your JEP from this PR

@andy-goryachev-oracle Can you mark conversations resolved if you think the issue has been discussed appropriately? This would help to organize all of the remaining points.

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

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

From angorya at openjdk.org  Wed Nov  6 18:49:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 18:49:41 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <sROExJQFDg6ep3o9nfrcVyKZiFDrhSnDU_43Vb-MWLo=.90eb4e34-a9d9-48a1-b80d-aceb3cd6ea51@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <D5TbsXA2L-WMQhYxJq6R_DEl6q2s-jm6aiZNSrAijts=.b118308f-4021-4687-988e-9f1afbb24aee@github.com>
 <sROExJQFDg6ep3o9nfrcVyKZiFDrhSnDU_43Vb-MWLo=.90eb4e34-a9d9-48a1-b80d-aceb3cd6ea51@github.com>
Message-ID: <J920rQFhd1YNdPsp2SWTT9XR8-flnN-9uTDGRQlVhoU=.dc58a834-4918-4ad3-aa9d-d01e15a5419a@github.com>

On Wed, 6 Nov 2024 18:41:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Can you mark conversations resolved

we are hitting the a github design problem here - as you correctly expect, the originator should, in theory, be able to mark conversation as resolved, but the only person who could is the PR submitter.

I started to use thumbsUp emoji to mark resolved/accepted answers, and I can go through and do the remaining ones, or mark the points that have not been answered yet (those exist).

Any other suggestions?

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

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

From mstrauss at openjdk.org  Wed Nov  6 18:49:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 18:49:42 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v15]
In-Reply-To: <cJRo38tG58tKap_cJVN4B42GHrI7udeQILPOvzpsBHw=.c4ee71f7-77bf-4359-9d8f-bd10fa4ea451@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>
 <cJRo38tG58tKap_cJVN4B42GHrI7udeQILPOvzpsBHw=.c4ee71f7-77bf-4359-9d8f-bd10fa4ea451@github.com>
Message-ID: <QcIJ6etWQIgvCJNjDoAW-ELutCuvOZsY7smdlSR6L2o=.09d6b6e8-325d-4a72-9e5b-e99adde818ba@github.com>

On Wed, 6 Nov 2024 10:32:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert doc change
>
> modules/javafx.graphics/src/test/addExports line 22:
> 
>> 20: --add-exports javafx.graphics/com.sun.javafx.iio=ALL-UNNAMED
>> 21: --add-exports javafx.graphics/com.sun.javafx.iio.png=ALL-UNNAMED
>> 22: --add-exports javafx.graphics/com.sun.javafx.iio.javax=ALL-UNNAMED
> 
> I am little bit hesitant about this package name. Using "javax" doesn't give clear idea what we are trying to do here.
> 
> May be com.sun.javafx.iio.imageio is a better option.

I'm not so sure about this, since there's already "iio" in in the name.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1831545973

From mstrauss at openjdk.org  Wed Nov  6 19:13:49 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 19:13:49 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v6]
In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
Message-ID: <moTnU9WZ6uo8puAeh4Avj09hWDgNKIMTaBgpdviUeMs=.2709cb0e-54d8-42a8-b490-d5338125f433@github.com>

> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
> 
> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)).
> 
> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change.

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

 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - add comment
 - Merge branch 'master' into feature/sealed-classes
 - remove documentation
 - Seal Node, Camera, LightBase, Shape, Shape3D

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

Changes: https://git.openjdk.org/jfx/pull/1556/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=05
  Stats: 215 lines in 46 files changed: 93 ins; 41 del; 81 mod
  Patch: https://git.openjdk.org/jfx/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556

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

From angorya at openjdk.org  Wed Nov  6 20:49:20 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 20:49:20 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v2]
In-Reply-To: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
Message-ID: <NnWy9S0unlT-DBwlbOs5NYUK-3aYNxXp1uopWaKFpGw=.fa5bbf26-0c3d-4c8e-af99-5997ba57fa3e@github.com>

> Public focus traversal API for use in custom controls.
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  missing newline

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1628/files
  - new: https://git.openjdk.org/jfx/pull/1628/files/0aba4924..8be95cb4

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

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

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

From kcr at openjdk.org  Wed Nov  6 21:10:48 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 21:10:48 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v2]
In-Reply-To: <NnWy9S0unlT-DBwlbOs5NYUK-3aYNxXp1uopWaKFpGw=.fa5bbf26-0c3d-4c8e-af99-5997ba57fa3e@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <NnWy9S0unlT-DBwlbOs5NYUK-3aYNxXp1uopWaKFpGw=.fa5bbf26-0c3d-4c8e-af99-5997ba57fa3e@github.com>
Message-ID: <BL0ta6pLNBIODJtY1xEIlLwI2XsSNzSjEmdaexqYEr4=.e26967a6-6d37-4a1f-ab75-4afed689a1f7@github.com>

On Wed, 6 Nov 2024 20:49:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing newline

I like this approach of providing the minimal API to do programmatic focus traversal without any additional (and unneeded) implementation changes.

The API looks good with a couple wording suggestions on the docs.

Can you provide some unit tests?

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

> 8533: 
> 8534:     /**
> 8535:      * Tries to move the focus from this {@code Node} in the specified direction.

Suggestion: `Tries` --> `Requests` (to better match the name of the method and the language in `requestFocus()`.

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

> 8537:      * A successful traversal results in a new {@code Node} being focused.
> 8538:      * <p>
> 8539:      * This method is expected to be called in response to a {@code KeyEvent}, since the {@code Node}

Suggestion: `, since the Node` --> `; therefore, the Node`

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

PR Review: https://git.openjdk.org/jfx/pull/1628#pullrequestreview-2419405812
PR Review Comment: https://git.openjdk.org/jfx/pull/1628#discussion_r1831700546
PR Review Comment: https://git.openjdk.org/jfx/pull/1628#discussion_r1831707394

From kcr at openjdk.org  Wed Nov  6 21:16:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 21:16:47 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v2]
In-Reply-To: <NnWy9S0unlT-DBwlbOs5NYUK-3aYNxXp1uopWaKFpGw=.fa5bbf26-0c3d-4c8e-af99-5997ba57fa3e@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <NnWy9S0unlT-DBwlbOs5NYUK-3aYNxXp1uopWaKFpGw=.fa5bbf26-0c3d-4c8e-af99-5997ba57fa3e@github.com>
Message-ID: <o9v1N9D-ErOCNYpaNxKRCpsQPnJrfcnWADQfcPIbNA0=.0398e4bf-dfdd-4a3a-9a62-2893c164d118@github.com>

On Wed, 6 Nov 2024 20:49:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing newline

One comment on the JEP:

The [Risks and Assumptions](https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md#risks-and-assumptions) section no longer matches the current proposal, since you are not proposing to "make the existing internal focus traversal methods public" nor is there any refactoring to introduce risk.

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

PR Comment: https://git.openjdk.org/jfx/pull/1628#issuecomment-2460796475

From kcr at openjdk.org  Wed Nov  6 21:19:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 21:19:49 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <J920rQFhd1YNdPsp2SWTT9XR8-flnN-9uTDGRQlVhoU=.dc58a834-4918-4ad3-aa9d-d01e15a5419a@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <D5TbsXA2L-WMQhYxJq6R_DEl6q2s-jm6aiZNSrAijts=.b118308f-4021-4687-988e-9f1afbb24aee@github.com>
 <sROExJQFDg6ep3o9nfrcVyKZiFDrhSnDU_43Vb-MWLo=.90eb4e34-a9d9-48a1-b80d-aceb3cd6ea51@github.com>
 <J920rQFhd1YNdPsp2SWTT9XR8-flnN-9uTDGRQlVhoU=.dc58a834-4918-4ad3-aa9d-d01e15a5419a@github.com>
Message-ID: <GkjmA78LEyaX-pC0Mvf5L3x196Epz62sW8edYcSsKEQ=.102c3039-58d3-4636-b917-639179fb234c@github.com>

On Wed, 6 Nov 2024 18:47:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Can you mark conversations resolved
> 
> we are hitting the a github design problem here - as you correctly expect, the originator should, in theory, be able to mark conversation as resolved, but the only person who could is the PR submitter.

This is, indeed, a limitation of GitHub.
  
> I started to use thumbsUp emoji to mark resolved/accepted answers, and I can go through and do the remaining ones, or mark the points that have not been answered yet (those exist).
> 
> Any other suggestions?

 I can't think of a better approach.

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

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

From kcr at openjdk.org  Wed Nov  6 21:29:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Nov 2024 21:29:49 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v15]
In-Reply-To: <QcIJ6etWQIgvCJNjDoAW-ELutCuvOZsY7smdlSR6L2o=.09d6b6e8-325d-4a72-9e5b-e99adde818ba@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>
 <cJRo38tG58tKap_cJVN4B42GHrI7udeQILPOvzpsBHw=.c4ee71f7-77bf-4359-9d8f-bd10fa4ea451@github.com>
 <QcIJ6etWQIgvCJNjDoAW-ELutCuvOZsY7smdlSR6L2o=.09d6b6e8-325d-4a72-9e5b-e99adde818ba@github.com>
Message-ID: <LMsDL6NFF_Aqcz6Mb9I9PxS6H2DsJx74hRqu6jsnbbQ=.78424b80-3816-4fc2-ab97-c0369d9e8149@github.com>

On Wed, 6 Nov 2024 18:46:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/addExports line 22:
>> 
>>> 20: --add-exports javafx.graphics/com.sun.javafx.iio=ALL-UNNAMED
>>> 21: --add-exports javafx.graphics/com.sun.javafx.iio.png=ALL-UNNAMED
>>> 22: --add-exports javafx.graphics/com.sun.javafx.iio.javax=ALL-UNNAMED
>> 
>> I am little bit hesitant about this package name. Using "javax" doesn't give clear idea what we are trying to do here.
>> 
>> May be com.sun.javafx.iio.imageio is a better option.
>
> I'm not so sure about this, since there's already "iio" in in the name.

How about one of the following as an alternative?

* com.sun.javafx.iio.java2d
* com.sun.javafx.iio.j2d
* com.sun.javafx.iio.desktop

That's roughly in preference order, but I like any of them better than `...iio.javax`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1831730909

From mstrauss at openjdk.org  Wed Nov  6 21:52:28 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 21:52:28 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v16]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <VTDWZ60R8QaW0jEC03VZBTeDXu4CznLS-Q24jGOSIqw=.d18c506f-e49b-4f0f-ba59-8c702ec05ab2@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

 - Merge branch 'master' into feature/ximageloader
 - rename iio.javax -> iio.java2d
 - revert doc change
 - Merge branch 'master' into feature/ximageloader
 - validate max image width/height
 - catch NoClassDefFoundError
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - Merge branch 'master' into feature/ximageloader
 - review comments
 - Merge branch 'master' into feature/ximageloader
 - Merge branch 'master' into feature/ximageloader
 - ... and 19 more: https://git.openjdk.org/jfx/compare/bd4bc057...7708b5cc

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

Changes: https://git.openjdk.org/jfx/pull/1593/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=15
  Stats: 3830 lines in 36 files changed: 3031 ins; 632 del; 167 mod
  Patch: https://git.openjdk.org/jfx/pull/1593.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1593/head:pull/1593

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

From mstrauss at openjdk.org  Wed Nov  6 21:52:28 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 6 Nov 2024 21:52:28 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v15]
In-Reply-To: <LMsDL6NFF_Aqcz6Mb9I9PxS6H2DsJx74hRqu6jsnbbQ=.78424b80-3816-4fc2-ab97-c0369d9e8149@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <kGu2cW48nRcg-wuTZKFt2ZJ5pCz1I9IW80CL42pjoc0=.e0bf6b33-e7b3-49e4-8021-e718d2eec318@github.com>
 <cJRo38tG58tKap_cJVN4B42GHrI7udeQILPOvzpsBHw=.c4ee71f7-77bf-4359-9d8f-bd10fa4ea451@github.com>
 <QcIJ6etWQIgvCJNjDoAW-ELutCuvOZsY7smdlSR6L2o=.09d6b6e8-325d-4a72-9e5b-e99adde818ba@github.com>
 <LMsDL6NFF_Aqcz6Mb9I9PxS6H2DsJx74hRqu6jsnbbQ=.78424b80-3816-4fc2-ab97-c0369d9e8149@github.com>
Message-ID: <cRsu5uGrvsATE84RGdsMEOrpWsWJe5rNIGb3iPQBmA4=.4d27e6b7-8685-4141-9943-6bf340036a54@github.com>

On Wed, 6 Nov 2024 21:26:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I'm not so sure about this, since there's already "iio" in in the name.
>
> How about one of the following as an alternative?
> 
> * com.sun.javafx.iio.java2d
> * com.sun.javafx.iio.j2d
> * com.sun.javafx.iio.desktop
> 
> That's roughly in preference order, but I like any of them better than `...iio.javax`.

Renamed to `com.sun.javafx.iio.java2d`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1831751600

From angorya at openjdk.org  Wed Nov  6 22:09:31 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 22:09:31 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v3]
In-Reply-To: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
Message-ID: <xJ9051NhEJBkPWvjZcjUe8lSdrO2FC_Ui5Er2LE01c4=.6546dbc4-7a99-4c54-8c71-1371c9a0424a@github.com>

> Public focus traversal API for use in custom controls.
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1628/files
  - new: https://git.openjdk.org/jfx/pull/1628/files/8be95cb4..3d034276

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

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

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

From angorya at openjdk.org  Wed Nov  6 22:27:46 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 22:27:46 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v3]
In-Reply-To: <xJ9051NhEJBkPWvjZcjUe8lSdrO2FC_Ui5Er2LE01c4=.6546dbc4-7a99-4c54-8c71-1371c9a0424a@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <xJ9051NhEJBkPWvjZcjUe8lSdrO2FC_Ui5Er2LE01c4=.6546dbc4-7a99-4c54-8c71-1371c9a0424a@github.com>
Message-ID: <pNDTAous9Tq2Pdqnprs9vYla7pVtyt5qpBOGqNeOHX0=.bea2870a-9e9b-4032-8854-23226de9858a@github.com>

On Wed, 6 Nov 2024 22:09:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

@nlisker or @mstr2 would you like to be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1628#issuecomment-2460914535

From angorya at openjdk.org  Wed Nov  6 22:56:51 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 22:56:51 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <ozBT47kU3c6HyV0vlJTxgPMq5jqU7TYt7g3O54zSYdU=.2309a416-bba8-486c-803a-3ac526439d49@github.com>

On Wed, 6 Nov 2024 10:42:47 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/EventHandlerPriority.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright year correction, may be it should be done as the last item before final push. (just in case if the PR reaches year 2025)

the copyright dates reflect the years the code became visible to the public.
it will be updated in 2025 if necessary.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831813760

From angorya at openjdk.org  Wed Nov  6 23:14:53 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 23:14:53 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <leAiGcDsMrDC1k6c0cI4CCC4wkZcoWQteqzwBSvmbIQ=.8e1c7dfe-eb44-4db1-aca9-159d91b79213@github.com>

On Wed, 6 Nov 2024 11:03:50 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/KeyEventMapper.java line 39:
> 
>> 37:     private static final int TYPED = 0x04;
>> 38: 
>> 39:     private int types;
> 
> I think, the 3 event types are mutually exclusive, either a key would be pressed or released or typed.
> so the name of this variable should be a singular form `type` or preferably `eventType`

all these are private fields of an internal implementation

> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/KeyEventMapper.java line 42:
> 
>> 40: 
>> 41:     public KeyEventMapper() {
>> 42:     }
> 
> May be remove empty default ctor.

why?  this class is not exposed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831825819
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831826424

From angorya at openjdk.org  Wed Nov  6 23:17:55 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Nov 2024 23:17:55 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <P2xMjxQlysXJ1lFqBjt_N9EA1SqHz9l2IEOk-3ibwR4=.3d8006a5-1827-4c73-94dc-d308596f5dd4@github.com>

On Wed, 6 Nov 2024 11:14:48 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 69:
> 
>> 67:         CTRL,
>> 68:         /** META modifier, mapped to COMMAND on Mac, META on Windows/Linux */
>> 69:         META,
> 
> The Command key on mac is mapped to both COMMAND(Line#65) and META.
> Is there a difference of right and left Command key ? If Yes, then may be it could be specified in the comment here.

There is no differentiation between left and right COMMAND key in KeyCode, so it is impossible to provide one.

Here, `KCondition` enum is private implementation detail.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1831838968

From andy.goryachev at oracle.com  Thu Nov  7 00:03:34 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 7 Nov 2024 00:03:34 +0000
Subject: Prioritized event handlers
In-Reply-To: <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
Message-ID: <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>

Dear Michael:

What happened to this proposal?  I would like to restart the discussion, if possible.

More specifically, I would like to discuss the following topics:


  1.  the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245<https://bugs.openjdk.org/browse/JDK-8231245> Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
  2.  dispatching of events that have been consumed (as mentioned in the earlier discussion)
  3.  problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246<https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
  4.  why do we need Event.copyFor() in the first place?  why does Event contain the target??

Too many topics, yes, we might want to split the discussion into separate threads.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/de629c65/attachment-0001.htm>

From mstrauss at openjdk.org  Thu Nov  7 00:57:49 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 00:57:49 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v3]
In-Reply-To: <xJ9051NhEJBkPWvjZcjUe8lSdrO2FC_Ui5Er2LE01c4=.6546dbc4-7a99-4c54-8c71-1371c9a0424a@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <xJ9051NhEJBkPWvjZcjUe8lSdrO2FC_Ui5Er2LE01c4=.6546dbc4-7a99-4c54-8c71-1371c9a0424a@github.com>
Message-ID: <QV0hEBImfmpDMR_C1g5zrFTGQOVS28i24u9I_wzqp3I=.658dc5df-e488-4842-bf4d-48f0dd8e399e@github.com>

On Wed, 6 Nov 2024 22:09:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

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

> 8547:         Direction d;
> 8548:         switch (direction) {
> 8549:         case DOWN:

Have you considered moving this code to the `Direction` enum, for example like this:

enum Direction {
    ...
    public static Direction of(TraversalDirection direction) {
        return switch (direction) {
            case DOWN -> DOWN;
            case LEFT -> LEFT;
            case NEXT -> NEXT;
            case PREVIOUS -> PREVIOUS;
            case RIGHT -> RIGHT;
            case UP -> UP;
        }
    }
}


This way we won't clutter up the already very long `Node` file with simple conversions, and the co-location of the conversion with the actual enum makes it easier to maintain the code as well.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1628#discussion_r1831911047

From mstrauss at openjdk.org  Thu Nov  7 03:09:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:09:52 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <qilpM-fP6grFT9d_INHSNK8m0oYA8_uyzXFGwonvCQs=.372d5230-ab41-443d-a5a2-08b15f74a2ef@github.com>

On Mon, 4 Nov 2024 23:01:03 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 74:
> 
>> 72:  *         <li>{@link Region} ? {@code window-button}, {@code maximize-button}
>> 73:  *         <li>{@link Region} ? {@code window-button}, {@code close-button}
>> 74:  *     </ul>
> 
> 1. I think this part (css ref) is rather important and maybe should be a part of this PR.  It would be nice to be able to review the CSS reference as a part of this PR.
> 2. if you don't kind, could you please link your JEP to the PR and the ticket?
> 3. could you please include the "application title" row in the table in the JEP?

1. As already mentioned, the CSS is a blackbox implementation detail.
2. Done.
3. Done.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831989442

From mstrauss at openjdk.org  Thu Nov  7 03:19:51 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:19:51 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <obVMWRuWa6SMeWAFBLv6jACzmxrStxPuWRn3tZr5E3o=.6daa8436-cfea-47cc-82ac-581fc0e061f4@github.com>

On Mon, 4 Nov 2024 20:33:42 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> buildSrc/win.gradle line 329:
> 
>> 327:         "winmm.lib", "imm32.lib", "shell32.lib", "Uiautomationcore.lib", "dwmapi.lib", "uxtheme.lib",
>> 328:         "/DELAYLOAD:user32.dll", "/DELAYLOAD:urlmon.dll", "/DELAYLOAD:winmm.dll", "/DELAYLOAD:shell32.dll",
>> 329:         "/DELAYLOAD:Uiautomationcore.dll", "/DELAYLOAD:dwmapi.dll", "/DELAYLOAD:uxtheme.dll"]).flatten()
> 
> minor suggestion: placing each entry on separate line might simplify maintenance and reduce merge conflicts.

I tried that, but this will add another 14 lines to the script. I'm inclined to not change it at this point.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 490:
> 
>> 488: 
>> 489:         private static final List<CssMetaData<?, ?>> METADATA =
>> 490:             Stream.concat(getClassCssMetaData().stream(), Stream.of(BUTTON_ORDER_METADATA)).toList();
> 
> [unrelated] this malloc galore deserves a utility method
> 
> https://bugs.openjdk.org/browse/JDK-8320796

I'd be in favor of getting rid of this "static inheritance" anti-pattern entirely. We should resurrect that discussion at some point.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 278:
> 
>> 276:         }
>> 277: 
>> 278:         View.EventHandler eventHandler = view.getEventHandler();
> 
> should this check be moved before L271?

Could be, but it really doesn't matter since `eventHandler` is basically never `null`.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinView.java line 115:
> 
>> 113: 
>> 114:             EventHandler eventHandler = getEventHandler();
>> 115:             if (eventHandler != null && eventHandler.pickDragAreaNode(wx, wy) != null) {
> 
> computing `wx, wy` may not be necessary if `eventHandler != null` check is moved before L111

True, but this is a menu event handler, i.e. it is only invoked if you right-click on a window title bar. There's no need to elide a double division here, especially given that `eventHandler` is basically never `null`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831992702
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831994096
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831994855
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831996006

From mstrauss at openjdk.org  Thu Nov  7 03:24:49 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:24:49 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
 <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
Message-ID: <cGgVLYNWiaNhAfEC-lB0TXDGvCwccvMcnLko-PL93JU=.a1f7f52e-0179-48cf-9487-e2a94cd9e74e@github.com>

On Tue, 5 Nov 2024 16:19:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> It links directly to `StageStyle.EXTENDED`, which contains lots of information. I don't think we need it here.
>> 
>> By the way, there are no support levels. The feature is supported in its entirety, as specified, on all desktop platforms. The table in the JEP is just informational to help OpenJFX developers understand what we're talking about. It's not a specification, and it can't be a specification because we either don't control things (for example, we have no influence on rounded corners, this could be changed with any future OS version) or because we'd be specifying us into a corner. There's no point prescribing every minute detail, and then being responsible to keep it working _exactly_ as described, even though the semantics are unchanged.
>> 
>> The relevant parts are specified in `StageStyle.EXTENDED` and `HeaderBar`, and I wouldn't go further than this. We don't specify the details of `StageStyle.DECORATED` for each OS; why should we do it for `StageStyle.EXTENDED`?
>
> I guess you are right here: from the app dev perspective, there is no difference between the supported platforms.  All good.
> 
> I do suggest to bring a condensed version of the table in the JEP (or a simple <ul> here to show what's being painted by the platform and what is not.  In other words, instead of reading 1k of text, I want to see a short list indicating that, for example, close button is painted by the platform, and the title bar is not painted.
> 
> Can you do something like this?  (Alternatively, there might be a better place to do that, but where?)

I don't want to do this, not because I don't want to write documentation, but because I see a very real risk of over-specifying these kinds of things. For app developers, it shouldn't matter if a close button is drawn by the OS or by JavaFX, the only thing that matters is that they _are_ drawn, and it is not the responsibility of the application developer to do it.

The specification of `StageStyle.EXTENDED` says:

* An extended window has the default window buttons (minimize, maximize, close), but no system-provided
* draggable header bar.


That's what is important in my opinion: if you choose this stage style, you will get window buttons (however this is done is of no interest), but you will not get a header bar.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1831999128

From mstrauss at openjdk.org  Thu Nov  7 03:28:49 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:28:49 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
 <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
Message-ID: <3A4GXvt7j92ous6JfryuKeDxafIF_Y1yGso7RVzzqYk=.dc2c3ff8-43c9-4208-a4d6-c649a60127d8@github.com>

On Tue, 5 Nov 2024 16:32:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The components can't be too large to fit:
>> `{@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children.`
>
> I want to know what happens when the layout is over-constrained.  For example, consider the layout to have the leading, the center, and the trailing nodes set, and the leading one has minWidth set to 10_000.  What happens?
> 
> Will the center and the trailing nodes be shown or clipped?  will the layout attempt to squeeze all three to fit the available space?
> 
> Can I get this answer from the javadoc?

I've added another sentence to the javadocs of `HeaderBar`:

 * All children will be resized to their preferred widths and extend the height of the {@code HeaderBar}.
 * {@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children. As a consequence,
 * its computed minimum width is sufficient to accommodate all of its children.


Does that help?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832000693

From mstrauss at openjdk.org  Thu Nov  7 03:34:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:34:41 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v24]
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: <juD0kTJ_X_CVZ4F7oXrZrpDV7zKLKpUoJo9nbe5xC_8=.d04c6a79-f580-4665-b97a-bd9c6268b618@github.com>

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

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

  HeaderBar javadoc change

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/ca9b325a..8e77a220

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

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 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  Thu Nov  7 03:34:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:34:41 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
 <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
Message-ID: <plj64QIX55VMOwsszTvgVYxh6nLVud7R0GrEkPS8Tnk=.a36b1bcb-4a24-422d-86d5-2906fe96917f@github.com>

On Tue, 5 Nov 2024 16:25:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> What do you mean with growing and shrinking?
>> 
>> An application can add a single `GridPane` to `HeaderBar.center`, and set its prefWidth to `POSITIVE_INFINITY`. This will extend the `GridPane` across the entire width of the header bar (excluding the window button area).
>
> maybe what's needed is to borrow some text from the `BorderPane`, along the lines of 
> 
>> "The top and bottom children will be resized to their preferred heights and extend the width of the border pane. The left and right children will be resized to their preferred widths and extend the length between the top and bottom nodes. And the center node will be resized to fill the available space in the middle. Any of the positions may be null. "
> 
> the important parts are
> - how children are resized
> - any can be null
> 
> (the layout in the HB is like the one in the `BorderPane`, right?)

Yes, `HeaderBar` is quite like `BorderPane`. I've added the information about nulls to the documentation, does that help?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832002965

From mstrauss at openjdk.org  Thu Nov  7 03:57:34 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:57:34 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v25]
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: <NQ2BgWY8_y2qm1eungwC2VhKlrCjW03mL_0SSnwESdY=.e58443f8-f2d9-4920-9109-a33904d18823@github.com>

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

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

  WindowControlsOverlay snapping

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/8e77a220..4336735a

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

  Stats: 18 lines in 1 file changed: 1 ins; 0 del; 17 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  Thu Nov  7 03:57:35 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:57:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
Message-ID: <2_HFYap8k5ZBzW-OQqHripFnpkZuKuF5T3JSfwNOKCk=.50ca5d89-eb7f-4d7d-b66d-b396de62af3d@github.com>

On Mon, 4 Nov 2024 23:36:21 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 23 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - macOS: dynamically adapt toolbar style to headerbar height
>>  - fix header bar height flicker
>>  - NPE
>>  - fix peer access outside of synchronizer
>>  - improve title text documentation
>>  - macOS: hide window title
>>  - better documentation
>>  - set minHeight to native height of title bar
>>  - ... and 13 more: https://git.openjdk.org/jfx/compare/58cd76a8...9b63892d
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 414:
> 
>> 412: 
>> 413:         double width = getWidth();
>> 414:         double button1Width = boundedWidth(button1);
> 
> Q: do we want to snap to pixel every time we use Node.[min/pref/max] values to avoid jitter and fuzzy edges?

I've added snapping at the appropriate points, and it makes a visible difference (less jitter).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832015247

From mstrauss at openjdk.org  Thu Nov  7 03:59:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 03:59:52 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <9ShCw0HhONnJ7s0DVRqRwvDdYbWt1EmHB0Fa4OYzv_A=.94336f53-1781-4640-911b-d3f669599b72@github.com>

On Tue, 5 Nov 2024 18:48:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBarBase.java line 190:
> 
>> 188:      * independent of layout orientation.
>> 189:      */
>> 190:     private final ReadOnlyObjectWrapper<Dimension2D> rightSystemInset =
> 
> Q: would it make sense to create a class with requestLayout() ?  this will save two class objects...

It'll only save one class (the other is not a `ReadOnlyObjectWrapper`). I'm probably leaving that as-is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832017038

From mstrauss at openjdk.org  Thu Nov  7 04:13:26 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 04:13:26 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v26]
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: <POXdxYxn8wX2JoyLEauGTltkWEg3IB29V4A6gxUXi_Q=.b484a2b4-bd86-4899-90de-f5cf8761d57e@github.com>

> Implementation of [`EXTENDED` stage style](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 33 commits:

 - Merge branch 'master' into feature/extended-window
 - add system menu documentation
 - WindowControlsOverlay snapping
 - HeaderBar javadoc change
 - refactor performWindowDrag
 - HeaderBar changes
 - EMPTY Dimension2D constant
 - use CsvSource in HeaderBarTest
 - stylistic changes
 - fix mirroring/unmirroring of X coord in win-glass
 - ... and 23 more: https://git.openjdk.org/jfx/compare/3d15a306...6a165368

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=25
  Stats: 4882 lines in 61 files changed: 4368 ins; 409 del; 105 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  Thu Nov  7 04:13:27 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 04:13:27 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
Message-ID: <LZEofdSr5IdUuRZJ9GRNyRCLl0J1L7GpZd4fLOmMtl4=.c04a6269-4c5c-478f-ae99-7463b5bad76d@github.com>

On Tue, 5 Nov 2024 18:54:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stylistic changes
>
> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 83:
> 
>> 81:      * <p>
>> 82:      * An extended window has the default window buttons (minimize, maximize, close), but no system-provided
>> 83:      * draggable header bar. Applications need to provide their own header bar by placing a single {@link HeaderBar}
> 
> I would like to see this expanded just a little bit, to give an example of what is (system menu, buttons) and is not rendered (rounded corners, app title), similarly to the the table in the JEP.
> 
> I would prefer a table or an `<ul>`, and I specifically want to include the window title.  Window title is a property, and I think it deserves a mention (will it be shown in the tray? in the "running applications" os widget?)
> 
> I don't know whether the best place to include that is here or in the `HeaderBar`.

As for window manager features like rounded corners, I am very certain that this should not be specified. It's out of our control. I've added a paragraph to `HeaderBar` that explains the system menu.

As for the application title, do you think that the existing specification is not sufficient?


 * An extended stage has no title text. Applications that require title text need to provide their own
 * implementation by placing a {@code Label} or a similar control in the custom header bar.
 * Note that the value of {@link Stage#titleProperty()} may still be used by the platform, one example
 * may be the title of miniaturized preview windows.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832027188

From mstrauss at openjdk.org  Thu Nov  7 04:14:30 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 04:14:30 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v17]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <tLGClO35TCX3_Bf0QMzxs0M5IUBonHzPpWgWAVYh8Ps=.05eea10a-9723-4ac5-98ed-bf2a64df6a74@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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/ximageloader
 - Merge branch 'master' into feature/ximageloader
 - rename iio.javax -> iio.java2d
 - revert doc change
 - Merge branch 'master' into feature/ximageloader
 - validate max image width/height
 - catch NoClassDefFoundError
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - Merge branch 'master' into feature/ximageloader
 - review comments
 - Merge branch 'master' into feature/ximageloader
 - ... and 20 more: https://git.openjdk.org/jfx/compare/3d15a306...3e1aae90

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

Changes: https://git.openjdk.org/jfx/pull/1593/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=16
  Stats: 3830 lines in 36 files changed: 3031 ins; 632 del; 167 mod
  Patch: https://git.openjdk.org/jfx/pull/1593.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1593/head:pull/1593

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

From mstrauss at openjdk.org  Thu Nov  7 04:15:55 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 04:15:55 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v7]
In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
Message-ID: <CKkA0xxY9s1RxrC2AUSJacWDKJcGmcGDfNrm71fKBBw=.d65addfc-7eab-4da7-8bd7-5963c6e5bbdd@github.com>

> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
> 
> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)).
> 
> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change.

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

 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - add comment
 - Merge branch 'master' into feature/sealed-classes
 - remove documentation
 - Seal Node, Camera, LightBase, Shape, Shape3D

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

Changes: https://git.openjdk.org/jfx/pull/1556/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=06
  Stats: 215 lines in 46 files changed: 93 ins; 41 del; 81 mod
  Patch: https://git.openjdk.org/jfx/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556

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

From jdv at openjdk.org  Thu Nov  7 07:15:59 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 7 Nov 2024 07:15:59 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
Message-ID: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>

> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
> 
> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
> 
> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update execute action

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1624/files
  - new: https://git.openjdk.org/jfx/pull/1624/files/d00dcdba..c40554a7

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

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

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

From jdv at openjdk.org  Thu Nov  7 07:20:48 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 7 Nov 2024 07:20:48 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v2]
In-Reply-To: <Fsx1cuZKicnCMQ9EpN_gGsXb4Hz9PIkKg4JbPXbFtLM=.40d23dbc-4f34-4f9f-84a8-b9e7c6a00aaf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <WLxvkC2i1u8Llzuuj7ncD7SzbDsMqLxvUNPMQEo3okc=.88294241-e428-4c0a-9012-1f6ab1b5b6c3@github.com>
 <Fsx1cuZKicnCMQ9EpN_gGsXb4Hz9PIkKg4JbPXbFtLM=.40d23dbc-4f34-4f9f-84a8-b9e7c6a00aaf@github.com>
Message-ID: <piiHOJ2-DwzuqEPVlkB0-X5XEpQMrQ3kcYbX_t4sVwQ=.75af7a6e-e0e7-4b1b-bd6d-e6002ff9ca92@github.com>

On Wed, 6 Nov 2024 15:37:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Accessible.java line 186:
> 
>> 184:             executeAction.action = action;
>> 185:             executeAction.parameters = parameters;
>> 186:             return executeAction;
> 
> I just noticed that this has the same problem that `getAttribute` had, which I reported and you fixed. The return value isn't used (so we didn't get a fail fast), but I'm pretty sure that this will cause a problem in that `executeAction` will never be executed.
> 
> For consistency, you might consider changing it in the same way as you did for `getAttribute`.

I have updated executeAction also. Looks like this call reaches from MacAccessible under certain conditions on macOS.

To instrument and verify, i ran different a11y tests in Hello toy(with VoiceOver) and found out that clicking on any Item in `HelloSimpleTableView` calls executeAction. So after the update also we receive this call.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1832169683

From dani-kurmann at protonmail.com  Thu Nov  7 09:58:27 2024
From: dani-kurmann at protonmail.com (dani-kurmann)
Date: Thu, 07 Nov 2024 09:58:27 +0000
Subject: Bugfix JDK-8229902 rendering time improvement
Message-ID: <vltfj9PwXeject3XvWpeuPHkKy8WXMN8hiTc2getvyyQOf5_k3hGcreZOxxHV-vEiMp2GuW3dTCAsLBLam5rDqLlFP-TjJP1o81VyazZg6c=@protonmail.com>

Sorry for my slow working pace, I can only spare about a day a week for this, hope this is ok.

I'm not done yet, but I could use a little feedback.

I tried different versions of separating the addBuffer and flush procedures, playing with the sequence of things, etc. Long story short: you can break alot of other things and make it work as a Bugfix. But the reliable Bugfix for JDK-8229902 is not calling flush() in freeSpace(int size).

However, there is definitifely a problem in the buffer management. All I can say with confidence for now is that there are unnecessary flush-calls, and I strongly suspect also unnecessary addBuffer-calls.

So there is rendering time and possibly memory usage to be optimised. And maybe not just for Canvas, this touches a lot more in webkit rendering.
I'm inclined to see this as two different problems: 1) Bug JDK-8229902 and 2) RenderQueue Buffer management
Maybe improving Buffer management will at some point also solve 1), so I will first look into 2) and then see if 1) is still needed.

I havent looked much into the memory usage yet. What seems to improve rendering time the most is removing the flush()-call from WCRenderQueue::addBuffer(). And as far as I see, this doesnt even break anything. (there are some flushBuffer()-calls to be further analysed, some can be changed to flush(), some can be omitted. I still think, something in flush() needs fixing, but im not there yet. Still learing how to navigate and understand the jfx codebase)
This improves Canvas rendering time by about one third. And as far as I see, doesnt break anything. Now when I broke my build-setup last week, I tested it out on jfx-21. There I could see also improvements in rendering other things than canvas.
Back on the current Master of openjfx, that effect seems to go away, or at least hide in the margin of error. Overall, Webkit rendering time has significantly improved since 21. However, Canvas rendering time improvement with the change in WCRenderQueue on the current master is still at around one third.

So I'm hoping that if I understand the rendering time improvements done since jfx 21, I might better understand the problem at hand.

I could do something like a binary search for the change. But with my build-time, this will take me about a day. So another week.

If someone knows from the top of their head, what commit(s) significantly improved WebKit rendering time since jfx21, you could really save me some time. Maybe this is a change in Webkit, but I suspect its a change in how jfx uses webkit.

I mean, even if its just the Canvas rendering time improvement, that is something worth looking into, right?

thanks for any help or hints

kind regards
Dani

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

On Friday, October 25th, 2024 at 1:28 PM, dani-kurmann <dani-kurmann at protonmail.com> wrote:

> Ok, the flush() function and its business in WCRenderQueue definitively deserve a closer look:
>
> I tried to do a proof-of-concept of how to test for this bug:
> https://github.com/CodeMonkeyIsland/Bugtest-JDK-8229902
>
> Its in a "its not pretty, but it works... sometimes"-state. Not ready for anything. But I discovered something interesting:
>
> Bug.java is the adjusted test (not unit test) from https://bugs.openjdk.org/browse/JDK-8229902, I passed the function in the html-document, because executeScript wasnt working. You can see the Bug there.
> In CanvasRenderingTest.java, I was testing out the testing strategy. Not very gracefully, I just handed over the pixelarray to be tested as a String and then decoded it into an int array again.
> I had some Problem with gc, I think, so I did the whole painting and extracting the imagadata with engine.executeScript(). - And the Bug doesnt show up anymore! ...
>
> I tried with bigger canvas, but it seems to work, just my test breaks at some point ... gc again I'm guessing.
>
> So definitively, the code is working as intended under some circumstances. So understanding when it works and when it doesnt work, probably means understanding the actual problem.
>
> Ill definitively have a deeper look into this sometime next week. And hopefully define the problem better.
>
> kind regards
>
> Dani
>
> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>
> On Monday, October 21st, 2024 at 6:19 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
>> Hi Dani,
>>
>> Welcome, and thank you for taking a look at this problem.
>>
>> I don't know enough yet to suggest the best course of action, but I took a quick look at it. I only see the one call to the native RenderingQueue::flush -- from freeSpace(int) if autoFlush is true. RenderingQueue::flush does a Java upcall to WCRenderQueue::fwkFlush which then calls WCRenderQueue::flush to decode and process the buffer. The native RenderingQueue::flushBuffer method does a Java upcall to WCRenderQueue::fwkAddBuffer which will add the buffer to a linked list of buffers, and then allocate a new BufferData wrapper object. It then calls WCRenderQueue::flush if the total size of the linked list of buffers it too large.
>>
>> One thing that should be checked is whether the call to WCRenderQueue::flush from native RenderingQueue::flushBuffers and then again from RenderingQueue::flush is causing the problem. Instrumenting the code on the Java side (which is usually easier if it gives you the information you need), might show what's going on.
>>
>> -- Kevin
>>
>> On 10/20/2024 7:01 AM, dani-kurmann wrote:
>>
>>> Hi everyone, nice to be here.
>>>
>>> I don't want to be overzealous, but I did sign up for a bugfix :)
>>> So here is me, socializing:
>>>
>>> I ran into the bug in a similiar scenario as described in the Bug report: https://bugs.openjdk.org/browse/JDK-8229902
>>>
>>> It's a buffer-problem. The culprit is the flush()-call on line 64 of /modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/RenderingQueue.cpp (in the freeSpace(int size) function)
>>>
>>> if (m_buffer && !m_buffer->hasFreeSpace(size)) {
>>> flushBuffer();
>>>
>>> if (m_autoFlush) {
>>> flush();
>>> }
>>>
>>> }
>>>
>>> this gets called, before a shape(or possibly something else) is added to the bytebuffer. If there is not enough space left in the buffer, here we go:
>>>
>>> The flushBuffer()-Call works fine. It sets up new Buffer Space as intended and, I guess, flushes the buffer.
>>> The flush()-call however leads to the described Bug. Just comment it out to test it. But thats not a bugfix, of course.
>>>
>>> Its very interesting where the two calls lead, this is right in the sweet spot between java and c++ and openjdk and webkit. I dont claim to understand half of it. But I do find it very interesting.
>>>
>>> This is the point where I ask for help: I can propose a bugfix, but I want to understand the issue deeper. Maybe this is a newbie-problem, but I have problems understanding the above mentioned sweet spot. So any advice is very welcome!
>>>
>>> Please DO correct me, and show me that other approach that I dont see, but the way I see it, there's two ways to approach this thing:
>>> A) Treat it as an initialisation-problem. e.g. There is nothing wrong with RenderingQueue, it just needs to be initialised with m_autoFlush=false. (in this case, at least)
>>> B) There seems to be something strange going on in RenderingQueue, understand it and fix it.
>>>
>>> A) is a lot easier: just follow back to where the RenderingQueue Constructor gets called: /modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/ImageBufferJavaBackend.cpp, line 82:
>>>
>>> auto context = makeUnique<GraphicsContextJava>(new PlatformContextJava(wcRenderQueue, true));
>>>
>>> The second Argument for the PlatformContext-constructor sets the m_autoFlush-Variable upon which the flush()-call in the freeSpace-function in RenderingQueue.cpp is conditional. Set it to false.
>>> as a git commit: https://github.com/CodeMonkeyIsland/jfx/commit/96f23307c7b6f324bac416b90c0eac4ad40b13a8
>>>
>>> pro:
>>> -simple fix
>>> -no need to mess around in more than one file
>>> -looks like this is a normal way to use RenderingQueue
>>> con:
>>> -more and more feels like a hack
>>>
>>> B) is can of worms: You can comment out not only the flush()-call in the freespace-function, but the flush() function itself. At first, I thought, that the flush()-function is still needed for a flush-call during flushBuffer() outside RenderingQueue. But that was not the same flush()-function. I just tested that, and it works. (havent checked yet, if this breaks something else)
>>> So assuming, the flush()-function is really defunct and not needed(and I would have to dive into this a lot deeper to make that statement as a fact), this is a chance to do some spring-cleaning in RenderingQueue. Again, I only see two main ways of approaching this:
>>> - make m_autoFlush obsolete. Since (if the assumption above is right) it already flushes regardless of how m_autoFlush is set, lets stop pretending. Remove m_autoFlush, adjust the constructors and the constructor calls outside RenderingQueue.
>>> - make m_autoFlush great again :) It would basically mean separating flushBuffer() into two functions, one that does the addBuffer-part and one that does the flushing. Then do the addBuffer unconditional and the flushing conditional on m_autoFlush().
>>> The "problem" here being, that other parts of the codebase seem to have gone the way of approach A). So another piece of code initializing RenderingQueue with m_autoFlush=false doesnt mean that they dont want to autoFlush. So every call of the constructor has to be analysed, if the intention is to autoflush or not. I dont see the use-case for not flushing. So this approach might very well lead to a situation, where every single constructor call sets m_autoFlush to true and m_autoFlush is kind of obsolete again. Or not. Anyone has an example, where it shouldnt flush? Maybe there is runtime to be optimised by planning when to flush? I dont know...
>>>
>>> pro:
>>> -if there is a problem in RenderingQueue, then thats the place to fix it! No matter the consequences.
>>> con:
>>> -even if its an easy fix in RenderingQueue, it will change its behaviour. Or at the very least make autoFlush obsolete. This has consequences.
>>>
>>> Approach B) seems a lot scarier than A), but if it must be done, it should be done. If you guys think this is the rabbit hole to be, I would be willing to go there. However, I don't feel competent to overview all the consequences of this. I could really need some advice and help on that road, I guess thats why Im here.
>>> I could imagine doing A) as a temporary fix and an exercise. Then exploring B) deeper with some help.
>>>
>>> As for testing: At first glance, this seems like a non-automated Mk.1 eyeball-test. On a closer look however, you could do something like the Bug-Class in the bug-report, extract the RenderingContext-imagedata, pass it from js to java and check the color of the pixel, to see if a shape has been drawn. A window would have to be opened for this test, I dont know if thats allowed. (But why not, I guess)
>>>
>>> So what do you guys think? Does that sound like a plan? Does this break something, that I don't see?
>>> I am new here. Anyone willing to have a look into this and maybe point me in the right direction sometimes?
>>>
>>> kind regards
>>>
>>> Dani Kurmann
>>>
>>> p.s. the Bug class in the bug report does not work anymore.(at least for me, forked or unforked) the script in executeScript doesn't get executed. As a quick fix, you can pass the function in the html document like so:
>>>
>>> WebEngine engine = webView.getEngine();
>>> String content="<html><body><canvas id=\"canvas\" width=\"600\" height=\"600\" style=\"border: 1px solid red;\"></canvas><script>window.onload = function() {";
>>> content=content
>>> + " var canvas = document.getElementById('canvas');"
>>> + " var c = canvas.getContext('2d');"
>>> + " var size = 4;"
>>> + " var step = size + 2;"
>>> + " for (var y = 0; y <= canvas.height; y = y + step) {"
>>> + " for (var x = 0; x <= canvas.width; x = x + step) {"
>>> + " c.fillRect(x, y, size, size);"
>>> + " }"
>>> + " }";
>>> content=content+"}</script></body></html>";  engine.loadContent(content);
>>>
>>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/04e89c81/attachment-0001.htm>

From kcr at openjdk.org  Thu Nov  7 12:30:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 12:30:49 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <UlF5REwL0IjifBg0znOyzZpPBLKbnGgnaW0L95zbcac=.ead6d95b-7d9c-4e79-ab62-3ed68c5c40b1@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

Looks good now.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2420841998

From kcr at openjdk.org  Thu Nov  7 12:48:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 12:48:47 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <msm26F0pDJzRvaHk9fex_wGhp2U8M0D4Lo3t7w-2J0g=.b23caf41-fdae-46e2-91f3-9a305602f9a3@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

Btw, the macOS / aarch64 build failure looks like its due to a deliberate change in the GitHub Actions runners. I filed [JDK-8343760](https://bugs.openjdk.org/browse/JDK-8343760) to track this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1624#issuecomment-2462149982

From kcr at openjdk.org  Thu Nov  7 13:07:56 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 13:07:56 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods
In-Reply-To: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
Message-ID: <6VG-Y6gjgAlOmiO5kcbBwCls8Bdi-1KMaY9ultsn9Ec=.7f26ed0d-a445-4d7b-9165-e653576030c8@github.com>

On Tue, 5 Nov 2024 19:37:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
> 
> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.

Reviewer: @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1627#issuecomment-2462192145

From kcr at openjdk.org  Thu Nov  7 13:17:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 13:17:33 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
Message-ID: <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>

> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
> 
> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.

Kevin Rushforth 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 'master' into 8342992-check-sm
 - 8342992: Security manager check should not use deprecated methods

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1627/files
  - new: https://git.openjdk.org/jfx/pull/1627/files/6e905c17..7ea58b33

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

  Stats: 905 lines in 40 files changed: 45 ins; 525 del; 335 mod
  Patch: https://git.openjdk.org/jfx/pull/1627.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1627/head:pull/1627

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

From duke at openjdk.org  Thu Nov  7 13:25:55 2024
From: duke at openjdk.org (Glavo)
Date: Thu, 7 Nov 2024 13:25:55 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
 <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
Message-ID: <zwBaiiMPO-sLikwjlCLEVxb_rvfWGdGn4DCD81I2pPY=.884dd641-9160-4fd2-8659-21269aba439e@github.com>

On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
>> 
>> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.
>
> Kevin Rushforth 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 'master' into 8342992-check-sm
>  - 8342992: Security manager check should not use deprecated methods

modules/javafx.base/src/main/java/com/sun/javafx/SecurityUtil.java line 48:

> 46:      * @throws UnsupportedOperationException if the security manager is enabled
> 47:      */
> 48:     public static void checkSecurityManager() {

Can we cache the results of the check?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1627#discussion_r1832674262

From john.hendrikx at gmail.com  Thu Nov  7 13:34:32 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 7 Nov 2024 14:34:32 +0100
Subject: Prioritized event handlers
In-Reply-To: <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>

Hi Andy,

Simply replacing a Skin can change the order of event handlers. In other 
words, if you registered your handler **after** the control was shown, 
then replace its Skin (which can be done by CSS state changes), then 
your handler is now called before the Skin/Behavior handlers.? Also 
removing your own handlers, then installing them back (in the same 
order) will not lead to the same result either.? The culprit is simply 
that two different parties (FX and the User) are sharing the same system 
-- this is mostly fine for properties, but Events are stateful, and so 
the processing order matters.

I've given this quite a lot of thought recently, and I also looked at 
the Spinner problem, and I think I do have an all encompassing solution 
for both the ordering problem and the Spinner problem.

Observations:

Controls have some trouble keeping their Skin internals hidden from the 
outside world.? For the user, the Spinner is a black box; it is the 
thing that gets the focus and accepts input, even though the actual 
implementation may be delegating this to an internal component (in the 
case of the default SpinnerSkin, a FakeFocusTextField -- a detail that 
you can see "leaking" out when registering a listener on Scene#focusOwner).

Secondly, because Skins are re-using normal controls, which only work 
when focused, they sometimes have to "fake" the focus (this is a problem 
I won't be solving in this post).? IMHO however, this should be handled 
differently altogether, perhaps with some kind of focus delegation 
mechanism as part of Behaviors -- the user observable focus should IMHO 
always be the Control, as it is a black box.? The current fake focus 
implementation tries to keep this hidden (by not firing change 
listeners) which is incredibly dubious, and also fails (you can still 
see internals being focused with Scene#focusOwner).

Analysis:

Inside SpinnerSkin, there is a lot of jumping through hoops?in the form 
of filtering events, copying them, and being aware of what the Behavior 
needs (SpinnerSkin for example knows that the Behavior has need of the 
UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this jumping through 
hoops is to make the internal TextField component receive events, but at 
the same time, not confusing the Behavior with duplicated events (as the 
Behavior handlers are in between the event root (the window) and the 
target (the internal textfield) events flow past the Behavior's handlers).

Solution:

The Behavior event handlers are at the Control level -- as far as the 
user is concerned, this is the target and also final destination (there 
is nothing deeper).? In effect you could say that the Behavior could 
register either a Filter or a Handler, and the result would be the same 
-- filtering down from Scene -> Node -> Spinner and then bubbling up 
from Spinner -> Node -> Scene, it shouldn't matter if the Behavior 
registers a filter or a handler as they're at the same position (of 
course there are some small differences, but I think we actually WANT 
filters in behaviors, more on this later).

One of the problems is that the event handlers in the behavior trigger 
**after** the internal TextField -- but we have the perfect mechanism to 
swap this around; if the Behavior registered a filter (which as I said 
earlier is sort of at the same position conceptually) then it would 
trigger **before** the internal TextField.? Spinner is then free to 
process and consume the arrow keys it needs, and the Skin would not need 
to be aware of this (ie. if a different Behavior decides to consume the 
+/- keys, then it would work with the current Skin).? The Skin then just 
forwards any events that arrive at the Control level still (everything 
minus potential arrow keys consumed by the Behavior) to the internal 
text field.

The second part of this solution relates to how to get Events to go down 
to the internal TextField.? Events are fired at the current focus owner, 
which is the Control.? The TextField only has fake focus.? So we need to 
take events that arrive at the Control, copy them and send them to the 
internal TextField.? However, there is a small problem -- the standard 
event mechanism will make such copies filter down from Window level all 
the way to the TextField level (passing the Spinner control).? But this 
isn't want we want at all.? Spinner is a black box; when we want to fire 
an event into the internals, we don't want this event to be exposed 
either (aside from the problems that causes, with having to be careful 
not to copy the event again as it will pass your forwarding handler 
again).? In effect, we want a different event dispatch hierarchy that is 
limited to the Control only.? So, why not build a dispatch chain that 
exclusively targets the internals?? This chain in this case only 
consists of one EventDispatcher, the one from the internal TextField.? 
The event copy is fired at it and the control works as expected.? It 
automatically also solves the "ENTER" problem described in 
https://bugs.openjdk.org/browse/JDK-8337246 without further hacks.

Takeaways:

I now think Behaviors should always be doing their event handling in 
filters, for the simple reason that they should get to act first before 
the Skin gets to act on an event;?events arriving at the Control level 
which is the final destination can be handled by either a handler or a 
filter and there would be no discernible difference.? Not only does this 
solve the problem with the internal text field and the Skin needing to 
be aware of what keys Behavior will be handling, but it also then makes 
behaviors always act before user event handlers, creating consistency 
here (ie. replacing a Skin will not affect event handler order).? This 
frees up handlers for user purposes.? The ordering problem moves to the 
filters, so we may still want to do a solution here (see below).

Event handler order when Skins get re-added:

Handlers registered by users can change order with regards to handlers 
registered by Behaviors when the Skin change or depending on when the 
user registered their handlers.? This is problematic for events as they 
are stateful and can be consumed, and so an order change can lead to a 
functionality change. This is not user friendly, as the user expects 
that the event handler and filter infrastructure is for their use 
alone.? I can see a few things we could explore further:

- See if it is possible to add some internal API that allows Behaviors 
to register filters or handlers first/last -- note that "last" here 
means **always** last, even when user handlers are added later (first 
would be an easier option).
- See if it is possible to change how `buildEventDispatchChain` works 
for Controls to include another dispatcher level exclusively for 
Behaviors.?? Where a standard chain would look like 
Window->Scene->Nodes->Control, it would become 
Window->Scene->Nodes->Control->Behavior(private) -- as this is a 
completely separate level, handlers from users and behaviors cannot 
become intertwined and so there will always be a predictable ordering


On 07/11/2024 01:03, Andy Goryachev wrote:
>
> Dear Michael:
>
> What happened to this proposal?? I would like to restart the 
> discussion, if possible.
>
> More specifically, I would like to discuss the following topics:
>
>  1. the reason the discussion was started was due to "priority
>     inversion" problem in Controls/Skins, ex.: JDK-8231245
>     <https://bugs.openjdk.org/browse/JDK-8231245>?Controls' behavior
>     must not depend on sequence of handler registration.? Do we have
>     this problem elsewhere?? In other words, does it make sense to
>     change the API at the EventDispatcher level when the problem can
>     be easily solved by the InputMap at the Control level?
>  2. dispatching of events that have been consumed (as mentioned in the
>     earlier discussion)
>  3. problem of creating unnecessary clones of events via
>     Event.copyFor(), leading to ex.: JDK-8337246
>     <https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not
>     consume ENTER KeyEvent when editor ActionEvent is consumed
>  4. why do we need Event.copyFor() in the first place?why does Event
>     contain the target??
>
1. You would have the same problem with other events that Behaviors 
listen to (ie. mouse events), or events they handle without going 
through the input map (TYPED, RELEASED), or events they handle with a 
parent event type (all KeyEvents, not a specific one).

2. This is IMHO a bug, it only happens for the same event type at one 
level, it should simply be fixed

3. See above, but in short, I think the problem is not the event clones, 
but the fact that these clones are traversing the entire 
Window->Scene->Node hierarchy.? Events with a restricted hierarchy solve 
this.

4. The target allows you to register the same event handler instance 
multiple times on multiple different controls without having to create a 
new lambda each time that knows which control (target) it is for. It has 
a similar function to the Observable parameter in InvalidationListeners 
and ChangeListeners.? In effect, having the Target will also make it 
possible in the future to share a single input map with all controls of 
the same type (currently there is a ton of memory being wasted here 
duplicating input maps, especially for controls with large input maps 
like TextFields).

--John

> Too many topics, yes, we might want to split the discussion into 
> separate threads.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Friday, October 27, 2023 at 19:41
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Re: Prioritized event handlers
>
> Here is the proposal:
> https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
>
> Comments are welcome.
>
>
> On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
> <andy.goryachev at oracle.com> wrote:
> >
> > Would it be possible to create a proposal in the JEP format 
> outlining the proposed public API?
> >
> >
> >
> > Thank you
> >
> > -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/c60730e7/attachment-0001.htm>

From jhendrikx at openjdk.org  Thu Nov  7 14:13:12 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 7 Nov 2024 14:13:12 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor
 ActionEvent is consumed
Message-ID: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>

This is a proof of concept fix for the linked issue.

We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.

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

Commit messages:
 - Proof of concept fix for Spinner event handling

Changes: https://git.openjdk.org/jfx/pull/1629/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1629&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337246
  Stats: 74 lines in 2 files changed: 22 ins; 35 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1629.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1629/head:pull/1629

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

From kcr at openjdk.org  Thu Nov  7 14:15:51 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 14:15:51 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <zwBaiiMPO-sLikwjlCLEVxb_rvfWGdGn4DCD81I2pPY=.884dd641-9160-4fd2-8659-21269aba439e@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
 <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
 <zwBaiiMPO-sLikwjlCLEVxb_rvfWGdGn4DCD81I2pPY=.884dd641-9160-4fd2-8659-21269aba439e@github.com>
Message-ID: <y3zhLFEuNMKnkps8eAlRmoYLF6Q2etUkZ_-qfRm_2I4=.6dfc5a44-dbe9-4636-937f-cf19c40e8494@github.com>

On Thu, 7 Nov 2024 13:23:24 GMT, Glavo <duke at openjdk.org> wrote:

>> Kevin Rushforth 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 'master' into 8342992-check-sm
>>  - 8342992: Security manager check should not use deprecated methods
>
> modules/javafx.base/src/main/java/com/sun/javafx/SecurityUtil.java line 48:
> 
>> 46:      * @throws UnsupportedOperationException if the security manager is enabled
>> 47:      */
>> 48:     public static void checkSecurityManager() {
> 
> Can we cache the results of the check?

I thought about doing that. In fact, I even coded it up, but since it only called at most 4 times (once for each of the 4 call sites) at startup, I wasn't sure it was worth it. I don't mind either way.

@arapte do you have an opinion?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1627#discussion_r1832751292

From lkostyra at openjdk.org  Thu Nov  7 14:43:56 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 7 Nov 2024 14:43:56 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <69TT9XUJOpcB7-q_JfTayUQVsQWMYhQWSOhXEd-am_A=.ed726a9e-546a-4302-9bca-96a5dd891025@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

Marked as reviewed by lkostyra (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2421179380

From jhendrikx at openjdk.org  Thu Nov  7 14:43:56 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 7 Nov 2024 14:43:56 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
Message-ID: <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com>

On Thu, 7 Nov 2024 14:08:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This is a proof of concept fix for the linked issue.
> 
> We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.

The failing `SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons` test is a bit odd; it expects that Enter in an **editable** Spinner should result in activating the Default Button.  However, a normal TextField doesn't do this either...

In a non-editable Spinner, the default button logic works as expected.

As it is, we can't have both; the bug wants to not have Enter bubbling up, but then the default button logic is not going to work. 

IMHO, Spinner's text field should work like regular text fields, so if Enter in those fields can't activate the default button, then neither should Spinner's editable field.

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

PR Comment: https://git.openjdk.org/jfx/pull/1629#issuecomment-2462406355

From kcr at openjdk.org  Thu Nov  7 15:27:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 15:27:54 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <kVx2zoCpCXj0E0W9MM4tTBcvj7f4qaReRfwKkzFX2Y8=.8e5ef8ed-aa27-4eed-b935-992d84eb48b9@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

@johanvos Do you want a chance to review the ios changes? The classes are being compiled with no errors after this fix, but we can't test it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1624#issuecomment-2462514050

From angorya at openjdk.org  Thu Nov  7 15:52:04 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 15:52:04 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v4]
In-Reply-To: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
Message-ID: <mbp-Z-X6WWm8APNPxhEEXBNnq4ycV1QYkmCJ0TZms5M=.f32416a8-7405-464a-8b31-925fcb8e4546@github.com>

> Public focus traversal API for use in custom controls.
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  direction

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1628/files
  - new: https://git.openjdk.org/jfx/pull/1628/files/3d034276..282589ca

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

  Stats: 37 lines in 2 files changed: 12 ins; 22 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1628.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1628/head:pull/1628

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

From angorya at openjdk.org  Thu Nov  7 16:06:54 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 16:06:54 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v21]
In-Reply-To: <LZEofdSr5IdUuRZJ9GRNyRCLl0J1L7GpZd4fLOmMtl4=.c04a6269-4c5c-478f-ae99-7463b5bad76d@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <RdNaNyDnaxXCYNLQvxaKtkeJPyFrU4Z-2Fe6UWDuJX8=.f433f9c1-d24f-4c7b-8ccd-b65726a39a4c@github.com>
 <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com>
 <LZEofdSr5IdUuRZJ9GRNyRCLl0J1L7GpZd4fLOmMtl4=.c04a6269-4c5c-478f-ae99-7463b5bad76d@github.com>
Message-ID: <QulaoUwyZa1MmtluCVUXcgxt6Ij1NH3DWc13-uZv-KA=.367bd2c6-c9d6-4486-aea5-dd0d187068e9@github.com>

On Thu, 7 Nov 2024 04:09:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 83:
>> 
>>> 81:      * <p>
>>> 82:      * An extended window has the default window buttons (minimize, maximize, close), but no system-provided
>>> 83:      * draggable header bar. Applications need to provide their own header bar by placing a single {@link HeaderBar}
>> 
>> I would like to see this expanded just a little bit, to give an example of what is (system menu, buttons) and is not rendered (rounded corners, app title), similarly to the the table in the JEP.
>> 
>> I would prefer a table or an `<ul>`, and I specifically want to include the window title.  Window title is a property, and I think it deserves a mention (will it be shown in the tray? in the "running applications" os widget?)
>> 
>> I don't know whether the best place to include that is here or in the `HeaderBar`.
>
> As for window manager features like rounded corners, I am very certain that this should not be specified. It's out of our control. I've added a paragraph to `HeaderBar` that explains the system menu.
> 
> As for the application title, do you think that the existing specification is not sufficient?
> 
> 
>  * An extended stage has no title text. Applications that require title text need to provide their own
>  * implementation by placing a {@code Label} or a similar control in the custom header bar.
>  * Note that the value of {@link Stage#titleProperty()} may still be used by the platform, one example
>  * may be the title of miniaturized preview windows.

I just think that one short table helps to get a lot of information across better than long winding paragraphs, but this is only my opinion/suggestion.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1832942753

From angorya at openjdk.org  Thu Nov  7 17:01:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 17:01:57 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v19]
In-Reply-To: <3A4GXvt7j92ous6JfryuKeDxafIF_Y1yGso7RVzzqYk=.dc2c3ff8-43c9-4208-a4d6-c649a60127d8@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <k_KrCCs8YyW02EgvEpxaprdiifqIIANJP_EYMknvCwE=.d1b4eacc-65df-476b-a7b3-35b5de05ed02@github.com>
 <Y4yUtRX0VfqFA5upKBB0bi9A6_YNOFZZ_o3sj3rhsGo=.f51647aa-1e4c-4856-b7bd-db867647d168@github.com>
 <Zr7W7PDyju4RtLC3FwouY1f94jezEetLAIkoK0-VnDg=.7d1272ea-8256-4f9d-aecc-27082f2dc78f@github.com>
 <q_k7m2adq6Mqxa2pmrZNzElXJ34XTxXqD9k9mLVbJzg=.2ff20dcb-b334-42eb-98c6-b7e3648b6ade@github.com>
 <3A4GXvt7j92ous6JfryuKeDxafIF_Y1yGso7RVzzqYk=.dc2c3ff8-43c9-4208-a4d6-c649a60127d8@github.com>
Message-ID: <_qTEBaehF5Rbg08yG-yrJlBEmQf1iBovlPakzHsGNi4=.3b91a82a-02c7-458a-8c94-e1820b973e18@github.com>

On Thu, 7 Nov 2024 03:25:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I want to know what happens when the layout is over-constrained.  For example, consider the layout to have the leading, the center, and the trailing nodes set, and the leading one has minWidth set to 10_000.  What happens?
>> 
>> Will the center and the trailing nodes be shown or clipped?  will the layout attempt to squeeze all three to fit the available space?
>> 
>> Can I get this answer from the javadoc?
>
> I've added another sentence to the javadocs of `HeaderBar`:
> 
>  * All children will be resized to their preferred widths and extend the height of the {@code HeaderBar}.
>  * {@code HeaderBar} honors the minimum, preferred, and maximum sizes of its children. As a consequence,
>  * its computed minimum size is sufficient to accommodate all of its children.
> 
> 
> Does that help?

it is probably ok - I am curious what @kevinrushforth might think.

it might be either obvious that the window will cut off the HB if it is wider than the window width, or it should be explicitly mentioned (there is probably enough text to go through to kind of understand the behavior in the case of over-constrained HB, or the dev can just try it).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1833038167

From andy.goryachev at oracle.com  Thu Nov  7 17:40:09 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 7 Nov 2024 17:40:09 +0000
Subject: Prioritized event handlers
In-Reply-To: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
Message-ID: <BL3PR10MB61854C22F6C0ED7C1682E525E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>

John:

Thanks for a detailed response and a very good analysis!

Allow me to summarize the points I took from your analysis:

- we do have a problem with event handler (EH) priority in Controls when skin changes
- there is still a bit of confusion/uncertainty re: skins/behaviors
- the fact that the skin uses a full-fledged control as an internal part without completely replacing (or deactivating) its own event handling might pose a problem
- solution is to keep the existing event handling paradigm but alter the plumbing of events, possibly by introducing custom dispatchers

(please correct me if I am wrong)

Before going forward, I wanted to as you (and everyone else): do we have this "priority inversion" problem only in Controls, or there exist other scenarios where the FX's dichotomy of event filter / event handler is insufficient?  I tried to pose this question earlier to Michael in the context of the original proposal of prioritized EHs, but I don't remember if it was answered (I might have missed a response, though).

If this problem exists only in Controls, then the scope of the problem is smaller and it does not require adding priorities to the EH, because other possibilities exist, and the discussion can be reduced to Controls.

Alternatively, if we can think of other scenarios where priority inversion is happening, then we should proceed with Michael's prioritized EHs.

I think this needs to be resolved first, before we can proceed with the problem of Controls.  (I'll start a separate thread).

What do you think?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, November 7, 2024 at 05:35
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers

Hi Andy,

Simply replacing a Skin can change the order of event handlers.  In other words, if you registered your handler **after** the control was shown, then replace its Skin (which can be done by CSS state changes), then your handler is now called before the Skin/Behavior handlers.  Also removing your own handlers, then installing them back (in the same order) will not lead to the same result either.  The culprit is simply that two different parties (FX and the User) are sharing the same system -- this is mostly fine for properties, but Events are stateful, and so the processing order matters.

I've given this quite a lot of thought recently, and I also looked at the Spinner problem, and I think I do have an all encompassing solution for both the ordering problem and the Spinner problem.

Observations:

Controls have some trouble keeping their Skin internals hidden from the outside world.  For the user, the Spinner is a black box; it is the thing that gets the focus and accepts input, even though the actual implementation may be delegating this to an internal component (in the case of the default SpinnerSkin, a FakeFocusTextField -- a detail that you can see "leaking" out when registering a listener on Scene#focusOwner).

Secondly, because Skins are re-using normal controls, which only work when focused, they sometimes have to "fake" the focus (this is a problem I won't be solving in this post).  IMHO however, this should be handled differently altogether, perhaps with some kind of focus delegation mechanism as part of Behaviors -- the user observable focus should IMHO always be the Control, as it is a black box.  The current fake focus implementation tries to keep this hidden (by not firing change listeners) which is incredibly dubious, and also fails (you can still see internals being focused with Scene#focusOwner).

Analysis:

Inside SpinnerSkin, there is a lot of jumping through hoops in the form of filtering events, copying them, and being aware of what the Behavior needs (SpinnerSkin for example knows that the Behavior has need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this jumping through hoops is to make the internal TextField component receive events, but at the same time, not confusing the Behavior with duplicated events (as the Behavior handlers are in between the event root (the window) and the target (the internal textfield) events flow past the Behavior's handlers).

Solution:

The Behavior event handlers are at the Control level -- as far as the user is concerned, this is the target and also final destination (there is nothing deeper).  In effect you could say that the Behavior could register either a Filter or a Handler, and the result would be the same -- filtering down from Scene -> Node -> Spinner and then bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the Behavior registers a filter or a handler as they're at the same position (of course there are some small differences, but I think we actually WANT filters in behaviors, more on this later).

One of the problems is that the event handlers in the behavior trigger **after** the internal TextField -- but we have the perfect mechanism to swap this around; if the Behavior registered a filter (which as I said earlier is sort of at the same position conceptually) then it would trigger **before** the internal TextField.  Spinner is then free to process and consume the arrow keys it needs, and the Skin would not need to be aware of this (ie. if a different Behavior decides to consume the +/- keys, then it would work with the current Skin).  The Skin then just forwards any events that arrive at the Control level still (everything minus potential arrow keys consumed by the Behavior) to the internal text field.

The second part of this solution relates to how to get Events to go down to the internal TextField.  Events are fired at the current focus owner, which is the Control.  The TextField only has fake focus.  So we need to take events that arrive at the Control, copy them and send them to the internal TextField.  However, there is a small problem -- the standard event mechanism will make such copies filter down from Window level all the way to the TextField level (passing the Spinner control).  But this isn't want we want at all.  Spinner is a black box; when we want to fire an event into the internals, we don't want this event to be exposed either (aside from the problems that causes, with having to be careful not to copy the event again as it will pass your forwarding handler again).  In effect, we want a different event dispatch hierarchy that is limited to the Control only.  So, why not build a dispatch chain that exclusively targets the internals?  This chain in this case only consists of one EventDispatcher, the one from the internal TextField.  The event copy is fired at it and the control works as expected.  It automatically also solves the "ENTER" problem described in https://bugs.openjdk.org/browse/JDK-8337246 without further hacks.

Takeaways:

I now think Behaviors should always be doing their event handling in filters, for the simple reason that they should get to act first before the Skin gets to act on an event; events arriving at the Control level which is the final destination can be handled by either a handler or a filter and there would be no discernible difference.  Not only does this solve the problem with the internal text field and the Skin needing to be aware of what keys Behavior will be handling, but it also then makes behaviors always act before user event handlers, creating consistency here (ie. replacing a Skin will not affect event handler order).  This frees up handlers for user purposes.  The ordering problem moves to the filters, so we may still want to do a solution here (see below).

Event handler order when Skins get re-added:

Handlers registered by users can change order with regards to handlers registered by Behaviors when the Skin change or depending on when the user registered their handlers.  This is problematic for events as they are stateful and can be consumed, and so an order change can lead to a functionality change. This is not user friendly, as the user expects that the event handler and filter infrastructure is for their use alone.  I can see a few things we could explore further:

- See if it is possible to add some internal API that allows Behaviors to register filters or handlers first/last -- note that "last" here means **always** last, even when user handlers are added later (first would be an easier option).
- See if it is possible to change how `buildEventDispatchChain` works for Controls to include another dispatcher level exclusively for Behaviors.   Where a standard chain would look like Window->Scene->Nodes->Control, it would become Window->Scene->Nodes->Control->Behavior(private) -- as this is a completely separate level, handlers from users and behaviors cannot become intertwined and so there will always be a predictable ordering

On 07/11/2024 01:03, Andy Goryachev wrote:
Dear Michael:

What happened to this proposal?  I would like to restart the discussion, if possible.

More specifically, I would like to discuss the following topics:


  1.  the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245<https://bugs.openjdk.org/browse/JDK-8231245> Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
  2.  dispatching of events that have been consumed (as mentioned in the earlier discussion)
  3.  problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246<https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
  4.  why do we need Event.copyFor() in the first place?  why does Event contain the target??

1. You would have the same problem with other events that Behaviors listen to (ie. mouse events), or events they handle without going through the input map (TYPED, RELEASED), or events they handle with a parent event type (all KeyEvents, not a specific one).

2. This is IMHO a bug, it only happens for the same event type at one level, it should simply be fixed

3. See above, but in short, I think the problem is not the event clones, but the fact that these clones are traversing the entire Window->Scene->Node hierarchy.  Events with a restricted hierarchy solve this.

4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

--John

Too many topics, yes, we might want to split the discussion into separate threads.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/8ff0298c/attachment-0001.htm>

From andy.goryachev at oracle.com  Thu Nov  7 17:54:26 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 7 Nov 2024 17:54:26 +0000
Subject: Prioritized event handlers
In-Reply-To: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
Message-ID: <BL3PR10MB61851661F97B39EAA56CF09BE55C2@BL3PR10MB6185.namprd10.prod.outlook.com>

1. You would have the same problem with other events that Behaviors listen to (ie. mouse events), or events they handle without going through the input map (TYPED, RELEASED), or events they handle with a parent event type (all KeyEvents, not a specific one).

I must clarify: ignoring Controls, do we have the priority inversion problem outside of Controls?

Assuming for a moment that the InputMap (in whatever form) can solve the EH problem **and** provide a way to create a static mapping, do we really need to add priority to the EH?

Can anyone think of a scenario outside of Controls?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, November 7, 2024 at 05:35
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers

Hi Andy,

Simply replacing a Skin can change the order of event handlers.  In other words, if you registered your handler **after** the control was shown, then replace its Skin (which can be done by CSS state changes), then your handler is now called before the Skin/Behavior handlers.  Also removing your own handlers, then installing them back (in the same order) will not lead to the same result either.  The culprit is simply that two different parties (FX and the User) are sharing the same system -- this is mostly fine for properties, but Events are stateful, and so the processing order matters.

I've given this quite a lot of thought recently, and I also looked at the Spinner problem, and I think I do have an all encompassing solution for both the ordering problem and the Spinner problem.

Observations:

Controls have some trouble keeping their Skin internals hidden from the outside world.  For the user, the Spinner is a black box; it is the thing that gets the focus and accepts input, even though the actual implementation may be delegating this to an internal component (in the case of the default SpinnerSkin, a FakeFocusTextField -- a detail that you can see "leaking" out when registering a listener on Scene#focusOwner).

Secondly, because Skins are re-using normal controls, which only work when focused, they sometimes have to "fake" the focus (this is a problem I won't be solving in this post).  IMHO however, this should be handled differently altogether, perhaps with some kind of focus delegation mechanism as part of Behaviors -- the user observable focus should IMHO always be the Control, as it is a black box.  The current fake focus implementation tries to keep this hidden (by not firing change listeners) which is incredibly dubious, and also fails (you can still see internals being focused with Scene#focusOwner).

Analysis:

Inside SpinnerSkin, there is a lot of jumping through hoops in the form of filtering events, copying them, and being aware of what the Behavior needs (SpinnerSkin for example knows that the Behavior has need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this jumping through hoops is to make the internal TextField component receive events, but at the same time, not confusing the Behavior with duplicated events (as the Behavior handlers are in between the event root (the window) and the target (the internal textfield) events flow past the Behavior's handlers).

Solution:

The Behavior event handlers are at the Control level -- as far as the user is concerned, this is the target and also final destination (there is nothing deeper).  In effect you could say that the Behavior could register either a Filter or a Handler, and the result would be the same -- filtering down from Scene -> Node -> Spinner and then bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the Behavior registers a filter or a handler as they're at the same position (of course there are some small differences, but I think we actually WANT filters in behaviors, more on this later).

One of the problems is that the event handlers in the behavior trigger **after** the internal TextField -- but we have the perfect mechanism to swap this around; if the Behavior registered a filter (which as I said earlier is sort of at the same position conceptually) then it would trigger **before** the internal TextField.  Spinner is then free to process and consume the arrow keys it needs, and the Skin would not need to be aware of this (ie. if a different Behavior decides to consume the +/- keys, then it would work with the current Skin).  The Skin then just forwards any events that arrive at the Control level still (everything minus potential arrow keys consumed by the Behavior) to the internal text field.

The second part of this solution relates to how to get Events to go down to the internal TextField.  Events are fired at the current focus owner, which is the Control.  The TextField only has fake focus.  So we need to take events that arrive at the Control, copy them and send them to the internal TextField.  However, there is a small problem -- the standard event mechanism will make such copies filter down from Window level all the way to the TextField level (passing the Spinner control).  But this isn't want we want at all.  Spinner is a black box; when we want to fire an event into the internals, we don't want this event to be exposed either (aside from the problems that causes, with having to be careful not to copy the event again as it will pass your forwarding handler again).  In effect, we want a different event dispatch hierarchy that is limited to the Control only.  So, why not build a dispatch chain that exclusively targets the internals?  This chain in this case only consists of one EventDispatcher, the one from the internal TextField.  The event copy is fired at it and the control works as expected.  It automatically also solves the "ENTER" problem described in https://bugs.openjdk.org/browse/JDK-8337246 without further hacks.

Takeaways:

I now think Behaviors should always be doing their event handling in filters, for the simple reason that they should get to act first before the Skin gets to act on an event; events arriving at the Control level which is the final destination can be handled by either a handler or a filter and there would be no discernible difference.  Not only does this solve the problem with the internal text field and the Skin needing to be aware of what keys Behavior will be handling, but it also then makes behaviors always act before user event handlers, creating consistency here (ie. replacing a Skin will not affect event handler order).  This frees up handlers for user purposes.  The ordering problem moves to the filters, so we may still want to do a solution here (see below).

Event handler order when Skins get re-added:

Handlers registered by users can change order with regards to handlers registered by Behaviors when the Skin change or depending on when the user registered their handlers.  This is problematic for events as they are stateful and can be consumed, and so an order change can lead to a functionality change. This is not user friendly, as the user expects that the event handler and filter infrastructure is for their use alone.  I can see a few things we could explore further:

- See if it is possible to add some internal API that allows Behaviors to register filters or handlers first/last -- note that "last" here means **always** last, even when user handlers are added later (first would be an easier option).
- See if it is possible to change how `buildEventDispatchChain` works for Controls to include another dispatcher level exclusively for Behaviors.   Where a standard chain would look like Window->Scene->Nodes->Control, it would become Window->Scene->Nodes->Control->Behavior(private) -- as this is a completely separate level, handlers from users and behaviors cannot become intertwined and so there will always be a predictable ordering

On 07/11/2024 01:03, Andy Goryachev wrote:
Dear Michael:

What happened to this proposal?  I would like to restart the discussion, if possible.

More specifically, I would like to discuss the following topics:


  1.  the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245<https://bugs.openjdk.org/browse/JDK-8231245> Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
  2.  dispatching of events that have been consumed (as mentioned in the earlier discussion)
  3.  problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246<https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
  4.  why do we need Event.copyFor() in the first place?  why does Event contain the target??

1. You would have the same problem with other events that Behaviors listen to (ie. mouse events), or events they handle without going through the input map (TYPED, RELEASED), or events they handle with a parent event type (all KeyEvents, not a specific one).

2. This is IMHO a bug, it only happens for the same event type at one level, it should simply be fixed

3. See above, but in short, I think the problem is not the event clones, but the fact that these clones are traversing the entire Window->Scene->Node hierarchy.  Events with a restricted hierarchy solve this.

4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

--John

Too many topics, yes, we might want to split the discussion into separate threads.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/0707275e/attachment-0001.htm>

From jvos at openjdk.org  Thu Nov  7 18:21:47 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 7 Nov 2024 18:21:47 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <zWZVv9HiJWhmLF6EFch8Mn6NQx3xtkJJ2KdgXvMBaTM=.b00a50a0-f48c-40cf-a72a-0afdf5439ee5@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

Marked as reviewed by jvos (Reviewer).

Changes in the Android/ios/monocle code look good.

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

PR Review: https://git.openjdk.org/jfx/pull/1624#pullrequestreview-2421809394
PR Comment: https://git.openjdk.org/jfx/pull/1624#issuecomment-2462929862

From jvos at openjdk.org  Thu Nov  7 18:21:48 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 7 Nov 2024 18:21:48 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <gBFiSTCViXrGfqG2pE2ySaOeJu8EJB23mJfXfjmoYyk=.96c546de-1b37-441d-81e1-e6b4f1a73c21@github.com>
Message-ID: <H0VA5ClYPeQDTK2DJzL-HszJcjCZnKu9y3vZz8Wa3Wc=.0c2bbe3d-2156-4b8e-b4d2-4259d4eb3dfb@github.com>

On Tue, 5 Nov 2024 13:40:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update execute action
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java line 40:
> 
>> 38:     private static native void _initIDs(); // init IDs for java callbacks from native
>> 39:     static {
>> 40:         Application.loadNativeLibrary();
> 
> @johanvos This looks good to me, but since it is in ios code, do you want to check it as well?

yes, this is fine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1624#discussion_r1833158399

From mstrauss at openjdk.org  Thu Nov  7 18:22:48 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 18:22:48 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v4]
In-Reply-To: <mbp-Z-X6WWm8APNPxhEEXBNnq4ycV1QYkmCJ0TZms5M=.f32416a8-7405-464a-8b31-925fcb8e4546@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <mbp-Z-X6WWm8APNPxhEEXBNnq4ycV1QYkmCJ0TZms5M=.f32416a8-7405-464a-8b31-925fcb8e4546@github.com>
Message-ID: <OUEX2UP6DgOqGtlXnBEzhzkqzIbCtsdk_w53kBgiS8M=.8dc3b563-974b-4525-84ad-c2120e4cff15@github.com>

On Thu, 7 Nov 2024 15:52:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   direction

I think the tests should also assert the `focusVisible` flag, as it is part of the specification of the new method.

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

PR Comment: https://git.openjdk.org/jfx/pull/1628#issuecomment-2462932305

From angorya at openjdk.org  Thu Nov  7 18:44:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 18:44:23 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v5]
In-Reply-To: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
Message-ID: <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>

> Public focus traversal API for use in custom controls.
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  focus visible

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1628/files
  - new: https://git.openjdk.org/jfx/pull/1628/files/282589ca..4cd02734

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

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

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

From angorya at openjdk.org  Thu Nov  7 18:44:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 18:44:23 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v4]
In-Reply-To: <OUEX2UP6DgOqGtlXnBEzhzkqzIbCtsdk_w53kBgiS8M=.8dc3b563-974b-4525-84ad-c2120e4cff15@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <mbp-Z-X6WWm8APNPxhEEXBNnq4ycV1QYkmCJ0TZms5M=.f32416a8-7405-464a-8b31-925fcb8e4546@github.com>
 <OUEX2UP6DgOqGtlXnBEzhzkqzIbCtsdk_w53kBgiS8M=.8dc3b563-974b-4525-84ad-c2120e4cff15@github.com>
Message-ID: <RMoEm4qUIqb8RC1yhvhq6QpKgdARld0GN3syEm6CL0I=.0def6bbd-621e-4dac-aef3-58c61094ed5f@github.com>

On Thu, 7 Nov 2024 18:20:36 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> tests should also assert the `focusVisible` flag

good point, thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1628#issuecomment-2462968353

From mstrauss at openjdk.org  Thu Nov  7 18:50:50 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 18:50:50 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v5]
In-Reply-To: <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
Message-ID: <g5he6XvO4aN7iQ-T4QtMIsSEAHGNxvSWK2G3Py7fNAI=.684d76a1-9542-41cd-bc7c-6338399a1abe@github.com>

On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   focus visible

Marked as reviewed by mstrauss (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1628#pullrequestreview-2421863193

From angorya at openjdk.org  Thu Nov  7 18:53:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 18:53:50 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v5]
In-Reply-To: <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
Message-ID: <3nM271bC-xQxs-5PdsQ4lup6DO9p_gk1t8e22ydPUQo=.810a73a5-87bd-43ce-8a5c-b0e4c5c07418@github.com>

On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   focus visible

@hjohn do you want to take a look as well?

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

PR Comment: https://git.openjdk.org/jfx/pull/1628#issuecomment-2462985689

From mstrauss at openjdk.org  Thu Nov  7 19:04:07 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 19:04:07 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v18]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <IZ0wHztUgrUTz0EL76PQURjh0RdnAadX6DOgEH82y-4=.f4f579c7-a2c6-4402-b646-17cba2b6b398@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:

 - move automatically added imports
 - rename test...javax -> test...java2d

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1593/files
  - new: https://git.openjdk.org/jfx/pull/1593/files/3e1aae90..2c0770d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=16-17

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

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

From andy.goryachev at oracle.com  Thu Nov  7 19:06:31 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 7 Nov 2024 19:06:31 +0000
Subject: Prioritized event handlers
In-Reply-To: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
Message-ID: <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>

> 4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

This is a very strange rationale, in my opinion.  And why talk about Controls when the Event.copyFor() is at the very fundamental level?  To me, this severely complicates everything, including breaking isConsumed() logic.  Sending events that are not designed to bubble up seems to run contrary to the whole event dispatching idea.  Are you trying to explain the current implementation?  Swing never needed to store the target in the event, and it works just fine.

This brings me to another problem I am struggling with: why expose the event dispatchers??  This should have never been done, in my opinion.  Swing's FwDispatcher is an implementation detail.  But instead, we seem to be dealing with unnecessarily increased complexity, including misbehaving EventDispatcher implementations.

May be it's just me, I don't see the beauty of this thing.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, November 7, 2024 at 05:35
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers

Hi Andy,

Simply replacing a Skin can change the order of event handlers.  In other words, if you registered your handler **after** the control was shown, then replace its Skin (which can be done by CSS state changes), then your handler is now called before the Skin/Behavior handlers.  Also removing your own handlers, then installing them back (in the same order) will not lead to the same result either.  The culprit is simply that two different parties (FX and the User) are sharing the same system -- this is mostly fine for properties, but Events are stateful, and so the processing order matters.

I've given this quite a lot of thought recently, and I also looked at the Spinner problem, and I think I do have an all encompassing solution for both the ordering problem and the Spinner problem.

Observations:

Controls have some trouble keeping their Skin internals hidden from the outside world.  For the user, the Spinner is a black box; it is the thing that gets the focus and accepts input, even though the actual implementation may be delegating this to an internal component (in the case of the default SpinnerSkin, a FakeFocusTextField -- a detail that you can see "leaking" out when registering a listener on Scene#focusOwner).

Secondly, because Skins are re-using normal controls, which only work when focused, they sometimes have to "fake" the focus (this is a problem I won't be solving in this post).  IMHO however, this should be handled differently altogether, perhaps with some kind of focus delegation mechanism as part of Behaviors -- the user observable focus should IMHO always be the Control, as it is a black box.  The current fake focus implementation tries to keep this hidden (by not firing change listeners) which is incredibly dubious, and also fails (you can still see internals being focused with Scene#focusOwner).

Analysis:

Inside SpinnerSkin, there is a lot of jumping through hoops in the form of filtering events, copying them, and being aware of what the Behavior needs (SpinnerSkin for example knows that the Behavior has need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this jumping through hoops is to make the internal TextField component receive events, but at the same time, not confusing the Behavior with duplicated events (as the Behavior handlers are in between the event root (the window) and the target (the internal textfield) events flow past the Behavior's handlers).

Solution:

The Behavior event handlers are at the Control level -- as far as the user is concerned, this is the target and also final destination (there is nothing deeper).  In effect you could say that the Behavior could register either a Filter or a Handler, and the result would be the same -- filtering down from Scene -> Node -> Spinner and then bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the Behavior registers a filter or a handler as they're at the same position (of course there are some small differences, but I think we actually WANT filters in behaviors, more on this later).

One of the problems is that the event handlers in the behavior trigger **after** the internal TextField -- but we have the perfect mechanism to swap this around; if the Behavior registered a filter (which as I said earlier is sort of at the same position conceptually) then it would trigger **before** the internal TextField.  Spinner is then free to process and consume the arrow keys it needs, and the Skin would not need to be aware of this (ie. if a different Behavior decides to consume the +/- keys, then it would work with the current Skin).  The Skin then just forwards any events that arrive at the Control level still (everything minus potential arrow keys consumed by the Behavior) to the internal text field.

The second part of this solution relates to how to get Events to go down to the internal TextField.  Events are fired at the current focus owner, which is the Control.  The TextField only has fake focus.  So we need to take events that arrive at the Control, copy them and send them to the internal TextField.  However, there is a small problem -- the standard event mechanism will make such copies filter down from Window level all the way to the TextField level (passing the Spinner control).  But this isn't want we want at all.  Spinner is a black box; when we want to fire an event into the internals, we don't want this event to be exposed either (aside from the problems that causes, with having to be careful not to copy the event again as it will pass your forwarding handler again).  In effect, we want a different event dispatch hierarchy that is limited to the Control only.  So, why not build a dispatch chain that exclusively targets the internals?  This chain in this case only consists of one EventDispatcher, the one from the internal TextField.  The event copy is fired at it and the control works as expected.  It automatically also solves the "ENTER" problem described in https://bugs.openjdk.org/browse/JDK-8337246 without further hacks.

Takeaways:

I now think Behaviors should always be doing their event handling in filters, for the simple reason that they should get to act first before the Skin gets to act on an event; events arriving at the Control level which is the final destination can be handled by either a handler or a filter and there would be no discernible difference.  Not only does this solve the problem with the internal text field and the Skin needing to be aware of what keys Behavior will be handling, but it also then makes behaviors always act before user event handlers, creating consistency here (ie. replacing a Skin will not affect event handler order).  This frees up handlers for user purposes.  The ordering problem moves to the filters, so we may still want to do a solution here (see below).

Event handler order when Skins get re-added:

Handlers registered by users can change order with regards to handlers registered by Behaviors when the Skin change or depending on when the user registered their handlers.  This is problematic for events as they are stateful and can be consumed, and so an order change can lead to a functionality change. This is not user friendly, as the user expects that the event handler and filter infrastructure is for their use alone.  I can see a few things we could explore further:

- See if it is possible to add some internal API that allows Behaviors to register filters or handlers first/last -- note that "last" here means **always** last, even when user handlers are added later (first would be an easier option).
- See if it is possible to change how `buildEventDispatchChain` works for Controls to include another dispatcher level exclusively for Behaviors.   Where a standard chain would look like Window->Scene->Nodes->Control, it would become Window->Scene->Nodes->Control->Behavior(private) -- as this is a completely separate level, handlers from users and behaviors cannot become intertwined and so there will always be a predictable ordering

On 07/11/2024 01:03, Andy Goryachev wrote:
Dear Michael:

What happened to this proposal?  I would like to restart the discussion, if possible.

More specifically, I would like to discuss the following topics:


  1.  the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245<https://bugs.openjdk.org/browse/JDK-8231245> Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
  2.  dispatching of events that have been consumed (as mentioned in the earlier discussion)
  3.  problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246<https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
  4.  why do we need Event.copyFor() in the first place?  why does Event contain the target??

1. You would have the same problem with other events that Behaviors listen to (ie. mouse events), or events they handle without going through the input map (TYPED, RELEASED), or events they handle with a parent event type (all KeyEvents, not a specific one).

2. This is IMHO a bug, it only happens for the same event type at one level, it should simply be fixed

3. See above, but in short, I think the problem is not the event clones, but the fact that these clones are traversing the entire Window->Scene->Node hierarchy.  Events with a restricted hierarchy solve this.

4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

--John

Too many topics, yes, we might want to split the discussion into separate threads.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/adc525d9/attachment-0001.htm>

From kcr at openjdk.org  Thu Nov  7 19:36:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 19:36:14 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed
Message-ID: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>

Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.

GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:

https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
https://github.com/actions/runner-images/issues/10703

The following build failed, suggesting that they may have done this already:

https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526

At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.

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

Commit messages:
 - 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which will be removed

Changes: https://git.openjdk.org/jfx/pull/1630/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343760
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1630.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1630/head:pull/1630

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

From angorya at openjdk.org  Thu Nov  7 19:36:14 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 19:36:14 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed
In-Reply-To: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
Message-ID: <pVOhMQDl9H0_eu2br8r9cxsm_fGoJ5l1N-3ND1c-vZM=.a18ccce2-615c-4578-a1ea-4cfb3193c2a1@github.com>

On Thu, 7 Nov 2024 19:29:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
> 
> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
> 
> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
> https://github.com/actions/runner-images/issues/10703
> 
> The following build failed, suggesting that they may have done this already:
> 
> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
> 
> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.

.github/workflows/submit.yml line 301:

> 299:           which ant
> 300:           ant -version
> 301:           sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer

do you think it might be better to comment out this line, in case we need emergency override?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1630#discussion_r1833243541

From kcr at openjdk.org  Thu Nov  7 19:45:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 19:45:22 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v2]
In-Reply-To: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
Message-ID: <daLUP3TVzLbh6SjeJ-G2Mrxoam3LKgJmDdXi4Wk14HU=.8c1c934b-6e58-4144-87d2-1f81a6c7169f@github.com>

> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
> 
> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
> 
> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
> https://github.com/actions/runner-images/issues/10703
> 
> The following build failed, suggesting that they may have done this already:
> 
> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
> 
> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Leave the Xcode-select commented out for clarity

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1630/files
  - new: https://git.openjdk.org/jfx/pull/1630/files/9ff1c041..25a2cf83

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

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

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

From angorya at openjdk.org  Thu Nov  7 19:45:22 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 19:45:22 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v2]
In-Reply-To: <daLUP3TVzLbh6SjeJ-G2Mrxoam3LKgJmDdXi4Wk14HU=.8c1c934b-6e58-4144-87d2-1f81a6c7169f@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
 <daLUP3TVzLbh6SjeJ-G2Mrxoam3LKgJmDdXi4Wk14HU=.8c1c934b-6e58-4144-87d2-1f81a6c7169f@github.com>
Message-ID: <n9dN086HwHVifPJ6Z_Mu5K97CxiTPH7cIOihe6Pq5Gk=.d7f320e8-24b8-43ee-9e9b-883ecfc64b7d@github.com>

On Thu, 7 Nov 2024 19:42:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
>> 
>> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
>> 
>> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
>> https://github.com/actions/runner-images/issues/10703
>> 
>> The following build failed, suggesting that they may have done this already:
>> 
>> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
>> 
>> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leave the Xcode-select commented out for clarity

lgtm

I know you dislike referencing JBS, but doing so always helps digital archaeologists...

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1630#pullrequestreview-2421960098

From kcr at openjdk.org  Thu Nov  7 19:45:23 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 19:45:23 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v2]
In-Reply-To: <pVOhMQDl9H0_eu2br8r9cxsm_fGoJ5l1N-3ND1c-vZM=.a18ccce2-615c-4578-a1ea-4cfb3193c2a1@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
 <pVOhMQDl9H0_eu2br8r9cxsm_fGoJ5l1N-3ND1c-vZM=.a18ccce2-615c-4578-a1ea-4cfb3193c2a1@github.com>
Message-ID: <C9x-_-G4-8HlZ22u5vb5n9ul1TSJHwG4S3qMw17LbeI=.bbbfaa94-c4e6-49e4-8093-a15fd51e9e99@github.com>

On Thu, 7 Nov 2024 19:33:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Leave the Xcode-select commented out for clarity
>
> .github/workflows/submit.yml line 301:
> 
>> 299:           which ant
>> 300:           ant -version
>> 301:           sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer
> 
> do you think it might be better to comment out this line, in case we need emergency override?

Sure. It might also save a question from someone wondering why we do an `xcode-select` for macOS 13 but not macOS 14

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1630#discussion_r1833251386

From john.hendrikx at gmail.com  Thu Nov  7 20:19:11 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 7 Nov 2024 21:19:11 +0100
Subject: Prioritized event handlers
In-Reply-To: <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
 <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <03126387-424d-4a7a-8314-7c6892421a7f@gmail.com>

On 07/11/2024 20:06, Andy Goryachev wrote:
>
> > 4. The target allows you to register the same event handler instance 
> multiple times on multiple different controls without having to create 
> a new lambda each time that knows which control (target) it is for. It 
> has a similar function to the Observable parameter in 
> InvalidationListeners and ChangeListeners.? In effect, having the 
> Target will also make it possible in the future to share a single 
> input map with all controls of the same type (currently there is a ton 
> of memory being wasted here duplicating input maps, especially for 
> controls with large input maps like TextFields).
>
> This is a very strange rationale, in my opinion.? And why talk about 
> Controls when the Event.copyFor() is at the very fundamental level?? 
> To me, this severely complicates everything, including breaking 
> isConsumed() logic.? Sending events that are not designed to bubble up 
> seems to run contrary to the whole event dispatching idea.? Are you 
> trying to explain the current implementation?? Swing never needed to 
> store the target in the event, and it works just fine.
>
FX is not Swing, they're designed quite differently in many areas, and 
trying to apply Swing logic to FX is not a good idea -- it would be 
better to look at what FX is doing an trying to understand why it does 
things the way it does.? I'm not sure what logic you are referring to 
that is being broken, but I never had problems with FX's event system, 
and am using it for several non-FX events to coordinate my UI.? I'm also 
unsure what you mean that the events are not designed to bubble up; they 
mostly certainly are.? Events are only copied when their target changes, 
and this normally doesn't happen (ie. the target is the focus owner or 
the control under the mouse).

For example, if I create an Event, and I set its target to X, then 
firing this event by calling X.fireEvent will not make any copies as it 
filters/bubbles.? If I however use that same event to call 
`otherNode.fireEvent` then a copy will be made to correct the target 
(the target becomes `otherNode`).? It will also make a copy if you leave 
the target `null`.

What you see for example in SpinnerSkin is that KeyEvents arrive and 
that they're targetted at the Spinner (which is correct as it has the 
focus).? However, as there is a "fake focus" control (the TextField) it 
won't get those events without some extra effort (if it had real focus, 
it would work out of the box, but we don't want the TextField to have 
focus as Controls are supposed to be black boxes).? So, these events 
need to be forwarded to the control that has focus within the Skin.? In 
order to do so, the target must be changed, which is why you need to 
make a copy.? The other reason you need to make a copy is that the 
original event is not done yet (it still needs to bubble up if it is not 
consumed).? The original event should only be consumed if the forwarded 
event is consumed, otherwise it should be left untouched.? The mistake 
made in SpinnerSkin is to have this retargetted event propagate all the 
way back down from Window/Scene, passing the Spinner Control again 
(where its handlers will see it),?to this new target, instead of only 
forwarding it within the Skin's internal hierarchy (understandably this 
is something that is non-obvious on how to do this, as the standard 
`fireEvent` code is no help to you there).

See this solution here: https://github.com/openjdk/jfx/pull/1629

It is simpler, removes dependencies between Skin and Behavior (yay) and 
probably faster as well (no 2nd event bubbling all the way down the 
hierarchy).

> This brings me to another problem I am struggling with: why expose the 
> event dispatchers??? This should have never been done, in my opinion.? 
> Swing's FwDispatcher is an implementation detail.? But instead, we 
> seem to be dealing with unnecessarily increased complexity, including 
> misbehaving EventDispatcher implementations.
>
I haven't quite figured out why that is public, and why you can set it, 
but I suppose it allows you to influence event handling even more 
radically then just installing filters/handlers, perhaps useful for 
custom controls or some skins (many odd choices seem to have been 
influenced by the needs Skins have).? Finding locations where this 
method this property is used may give some insight why this was done.

One use case seems to be that it allows you to fire an event directly at 
a single Node (or a partial hierarchy) without going through a full 
dispatch/bubbling phase from the Window level.? In my case, I used it 
now to solve the problem with SpinnerSkin, so it does seem to have some 
merit in complex scenario's.

--John

> May be it's just me, I don't see the beauty of this thing.
>

> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John 
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Thursday, November 7, 2024 at 05:35
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Prioritized event handlers
>
> Hi Andy,
>
> Simply replacing a Skin can change the order of event handlers.? In 
> other words, if you registered your handler **after** the control was 
> shown, then replace its Skin (which can be done by CSS state changes), 
> then your handler is now called before the Skin/Behavior handlers.? 
> Also removing your own handlers, then installing them back (in the 
> same order) will not lead to the same result either.? The culprit is 
> simply that two different parties (FX and the User) are sharing the 
> same system -- this is mostly fine for properties, but Events are 
> stateful, and so the processing order matters.
>
> I've given this quite a lot of thought recently, and I also looked at 
> the Spinner problem, and I think I do have an all encompassing 
> solution for both the ordering problem and the Spinner problem.
>
> Observations:
>
> Controls have some trouble keeping their Skin internals hidden from 
> the outside world.? For the user, the Spinner is a black box; it is 
> the thing that gets the focus and accepts input, even though the 
> actual implementation may be delegating this to an internal component 
> (in the case of the default SpinnerSkin, a FakeFocusTextField -- a 
> detail that you can see "leaking" out when registering a listener on 
> Scene#focusOwner).
>
> Secondly, because Skins are re-using normal controls, which only work 
> when focused, they sometimes have to "fake" the focus (this is a 
> problem I won't be solving in this post).? IMHO however, this should 
> be handled differently altogether, perhaps with some kind of focus 
> delegation mechanism as part of Behaviors -- the user observable focus 
> should IMHO always be the Control, as it is a black box.? The current 
> fake focus implementation tries to keep this hidden (by not firing 
> change listeners) which is incredibly dubious, and also fails (you can 
> still see internals being focused with Scene#focusOwner).
>
> Analysis:
>
> Inside SpinnerSkin, there is a lot of jumping through hoops?in the 
> form of filtering events, copying them, and being aware of what the 
> Behavior needs (SpinnerSkin for example knows that the Behavior has 
> need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this 
> jumping through hoops is to make the internal TextField component 
> receive events, but at the same time, not confusing the Behavior with 
> duplicated events (as the Behavior handlers are in between the event 
> root (the window) and the target (the internal textfield) events flow 
> past the Behavior's handlers).
>
> Solution:
>
> The Behavior event handlers are at the Control level -- as far as the 
> user is concerned, this is the target and also final destination 
> (there is nothing deeper).? In effect you could say that the Behavior 
> could register either a Filter or a Handler, and the result would be 
> the same -- filtering down from Scene -> Node -> Spinner and then 
> bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the 
> Behavior registers a filter or a handler as they're at the same 
> position (of course there are some small differences, but I think we 
> actually WANT filters in behaviors, more on this later).
>
> One of the problems is that the event handlers in the behavior trigger 
> **after** the internal TextField -- but we have the perfect mechanism 
> to swap this around; if the Behavior registered a filter (which as I 
> said earlier is sort of at the same position conceptually) then it 
> would trigger **before** the internal TextField.? Spinner is then free 
> to process and consume the arrow keys it needs, and the Skin would not 
> need to be aware of this (ie. if a different Behavior decides to 
> consume the +/- keys, then it would work with the current Skin).? The 
> Skin then just forwards any events that arrive at the Control level 
> still (everything minus potential arrow keys consumed by the Behavior) 
> to the internal text field.
>
> The second part of this solution relates to how to get Events to go 
> down to the internal TextField.? Events are fired at the current focus 
> owner, which is the Control. The TextField only has fake focus.? So we 
> need to take events that arrive at the Control, copy them and send 
> them to the internal TextField.? However, there is a small problem -- 
> the standard event mechanism will make such copies filter down from 
> Window level all the way to the TextField level (passing the Spinner 
> control).? But this isn't want we want at all.? Spinner is a black 
> box; when we want to fire an event into the internals, we don't want 
> this event to be exposed either (aside from the problems that causes, 
> with having to be careful not to copy the event again as it will pass 
> your forwarding handler again).? In effect, we want a different event 
> dispatch hierarchy that is limited to the Control only. So, why not 
> build a dispatch chain that exclusively targets the internals?? This 
> chain in this case only consists of one EventDispatcher, the one from 
> the internal TextField.? The event copy is fired at it and the control 
> works as expected.? It automatically also solves the "ENTER" problem 
> described in https://bugs.openjdk.org/browse/JDK-8337246 without 
> further hacks.
>
> Takeaways:
>
> I now think Behaviors should always be doing their event handling in 
> filters, for the simple reason that they should get to act first 
> before the Skin gets to act on an event;?events arriving at the 
> Control level which is the final destination can be handled by either 
> a handler or a filter and there would be no discernible difference.? 
> Not only does this solve the problem with the internal text field and 
> the Skin needing to be aware of what keys Behavior will be handling, 
> but it also then makes behaviors always act before user event 
> handlers, creating consistency here (ie. replacing a Skin will not 
> affect event handler order).? This frees up handlers for user 
> purposes.? The ordering problem moves to the filters, so we may still 
> want to do a solution here (see below).
>
> Event handler order when Skins get re-added:
>
> Handlers registered by users can change order with regards to handlers 
> registered by Behaviors when the Skin change or depending on when the 
> user registered their handlers.? This is problematic for events as 
> they are stateful and can be consumed, and so an order change can lead 
> to a functionality change. This is not user friendly, as the user 
> expects that the event handler and filter infrastructure is for their 
> use alone.? I can see a few things we could explore further:
>
> - See if it is possible to add some internal API that allows Behaviors 
> to register filters or handlers first/last -- note that "last" here 
> means **always** last, even when user handlers are added later (first 
> would be an easier option).
> - See if it is possible to change how `buildEventDispatchChain` works 
> for Controls to include another dispatcher level exclusively for 
> Behaviors. Where a standard chain would look like 
> Window->Scene->Nodes->Control, it would become 
> Window->Scene->Nodes->Control->Behavior(private) -- as this is a 
> completely separate level, handlers from users and behaviors cannot 
> become intertwined and so there will always be a predictable ordering
>
> On 07/11/2024 01:03, Andy Goryachev wrote:
>
>     Dear Michael:
>
>     What happened to this proposal?? I would like to restart the
>     discussion, if possible.
>
>     More specifically, I would like to discuss the following topics:
>
>      1. the reason the discussion was started was due to "priority
>         inversion" problem in Controls/Skins, ex.: JDK-8231245
>         <https://bugs.openjdk.org/browse/JDK-8231245>?Controls'
>         behavior must not depend on sequence of handler registration.?
>         Do we have this problem elsewhere?? In other words, does it
>         make sense to change the API at the EventDispatcher level when
>         the problem can be easily solved by the InputMap at the
>         Control level?
>      2. dispatching of events that have been consumed (as mentioned in
>         the earlier discussion)
>      3. problem of creating unnecessary clones of events via
>         Event.copyFor(), leading to ex.: JDK-8337246
>         <https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does
>         not consume ENTER KeyEvent when editor ActionEvent is consumed
>      4. why do we need Event.copyFor() in the first place?why does
>         Event contain the target??
>
> 1. You would have the same problem with other events that Behaviors 
> listen to (ie. mouse events), or events they handle without going 
> through the input map (TYPED, RELEASED), or events they handle with a 
> parent event type (all KeyEvents, not a specific one).
>
> 2. This is IMHO a bug, it only happens for the same event type at one 
> level, it should simply be fixed
>
> 3. See above, but in short, I think the problem is not the event 
> clones, but the fact that these clones are traversing the entire 
> Window->Scene->Node hierarchy.? Events with a restricted hierarchy 
> solve this.
>
> 4. The target allows you to register the same event handler instance 
> multiple times on multiple different controls without having to create 
> a new lambda each time that knows which control (target) it is for. It 
> has a similar function to the Observable parameter in 
> InvalidationListeners and ChangeListeners.? In effect, having the 
> Target will also make it possible in the future to share a single 
> input map with all controls of the same type (currently there is a ton 
> of memory being wasted here duplicating input maps, especially for 
> controls with large input maps like TextFields).
>
> --John
>
>     Too many topics, yes, we might want to split the discussion into
>     separate threads.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau?
>     <michaelstrau2 at gmail.com> <mailto:michaelstrau2 at gmail.com>
>     *Date: *Friday, October 27, 2023 at 19:41
>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: Prioritized event handlers
>
>     Here is the proposal:
>     https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
>
>     Comments are welcome.
>
>
>     On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
>     <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>     >
>     > Would it be possible to create a proposal in the JEP format
>     outlining the proposed public API?
>     >
>     >
>     >
>     > Thank you
>     >
>     > -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241107/96fd099f/attachment-0001.htm>

From jhendrikx at openjdk.org  Thu Nov  7 20:36:50 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 7 Nov 2024 20:36:50 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
Message-ID: <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com>

> This is a proof of concept fix for the linked issue.
> 
> We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Change default button tests to use non-editable spinner

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1629/files
  - new: https://git.openjdk.org/jfx/pull/1629/files/afef5153..4e6dafca

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

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

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

From angorya at openjdk.org  Thu Nov  7 20:45:53 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 20:45:53 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <ObYCHLeJIxftlsc71r4lz_q15jkpv42N1oktbwYR9SY=.cd86687c-789b-4bca-a32f-2c73c89c3571@github.com>

On Wed, 6 Nov 2024 11:37:07 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 97:
> 
>> 95: 
>> 96:     /**
>> 97:      * Utility method creates a KeyBinding corresponding to a key press.
> 
> Minor: typo / rewording. Similar comment applies to other helper methods of this class.
> `Utility method creates`  -> `Utility method that creates`  OR  `Utility method to create`

re-phrased in all related methods, thanks!

> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 257:
> 
>> 255:      */
>> 256:     public boolean isCommand() {
>> 257:         return modifiers.contains(KCondition.COMMAND);
> 
> Could safe guard with `if (PlatformUtil.isMac())` check to `return false` if not a mac platform

I wonder if these is* are needed at all...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833340978
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833342063

From angorya at openjdk.org  Thu Nov  7 21:11:31 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 21:11:31 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <C-Au07wnGBoUw5zGYGm8Gly_hVur8pmtxD1vtAAwD04=.635db332-99ca-4214-8705-0da2aae17eef@github.com>

On Wed, 6 Nov 2024 11:52:35 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 708:
> 
>> 706:             } else if (linux) {
>> 707:                 replace(KCondition.SHORTCUT, KCondition.CTRL);
>> 708:             }
> 
> the two else blocks can be combined into one.
> 
> else if (win || linux) {
>     replace(KCondition.SHORTCUT, KCondition.CTRL);
> }

unless there are more changes due to e.g. using mac hardware with linux...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833365199

From kcr at openjdk.org  Thu Nov  7 22:14:21 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 22:14:21 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v3]
In-Reply-To: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
Message-ID: <9zM9eBSMdUqc2v5wXEVirjAedQOTicriQIbzEAI4w0Y=.2b2578a9-bf5a-4e57-8069-ac12162aca15@github.com>

> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
> 
> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
> 
> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
> https://github.com/actions/runner-images/issues/10703
> 
> The following build failed, suggesting that they may have done this already:
> 
> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
> 
> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1630/files
  - new: https://git.openjdk.org/jfx/pull/1630/files/25a2cf83..fe739824

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

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

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

From angorya at openjdk.org  Thu Nov  7 22:14:21 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 22:14:21 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v3]
In-Reply-To: <9zM9eBSMdUqc2v5wXEVirjAedQOTicriQIbzEAI4w0Y=.2b2578a9-bf5a-4e57-8069-ac12162aca15@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
 <9zM9eBSMdUqc2v5wXEVirjAedQOTicriQIbzEAI4w0Y=.2b2578a9-bf5a-4e57-8069-ac12162aca15@github.com>
Message-ID: <SIrUuCLLFwCDr-tBVN_KbJKkiRpZ0hKFkxehEtVkdEQ=.cad13a34-551d-4622-a744-727d64012fce@github.com>

On Thu, 7 Nov 2024 22:11:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
>> 
>> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
>> 
>> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
>> https://github.com/actions/runner-images/issues/10703
>> 
>> The following build failed, suggesting that they may have done this already:
>> 
>> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
>> 
>> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1630#pullrequestreview-2422262275

From kcr at openjdk.org  Thu Nov  7 22:14:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Nov 2024 22:14:22 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v2]
In-Reply-To: <n9dN086HwHVifPJ6Z_Mu5K97CxiTPH7cIOihe6Pq5Gk=.d7f320e8-24b8-43ee-9e9b-883ecfc64b7d@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
 <daLUP3TVzLbh6SjeJ-G2Mrxoam3LKgJmDdXi4Wk14HU=.8c1c934b-6e58-4144-87d2-1f81a6c7169f@github.com>
 <n9dN086HwHVifPJ6Z_Mu5K97CxiTPH7cIOihe6Pq5Gk=.d7f320e8-24b8-43ee-9e9b-883ecfc64b7d@github.com>
Message-ID: <4q2-Y-zq0YznyQ44fbDWzRJ-LGEYGjlSqe-iTxWa7QU=.d43b2c6d-34df-4fee-a797-064d4c4d25a6@github.com>

On Thu, 7 Nov 2024 19:41:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I know you dislike referencing JBS, but doing so always helps digital archaeologists...

You're right. I dislike peppering our code with a pointer to a bug ID, at least as a general practice. There are always exceptions, but there needs to be a good reason.

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

PR Comment: https://git.openjdk.org/jfx/pull/1630#issuecomment-2463311158

From mstrauss at openjdk.org  Thu Nov  7 22:27:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 7 Nov 2024 22:27:39 GMT
Subject: RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which
 will be removed [v2]
In-Reply-To: <n9dN086HwHVifPJ6Z_Mu5K97CxiTPH7cIOihe6Pq5Gk=.d7f320e8-24b8-43ee-9e9b-883ecfc64b7d@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
 <daLUP3TVzLbh6SjeJ-G2Mrxoam3LKgJmDdXi4Wk14HU=.8c1c934b-6e58-4144-87d2-1f81a6c7169f@github.com>
 <n9dN086HwHVifPJ6Z_Mu5K97CxiTPH7cIOihe6Pq5Gk=.d7f320e8-24b8-43ee-9e9b-883ecfc64b7d@github.com>
Message-ID: <s9HqeG-IhQq0FUo76j2JQ0zNUycO2J1MXnpJInmpv3c=.a8efc6a0-ac81-48df-901a-0027aa3d3f51@github.com>

On Thu, 7 Nov 2024 19:41:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> lgtm
> 
> I know you dislike referencing JBS, but doing so always helps digital archaeologists...

Every commit already contains the JBS ticket, and it's easy to list all commits for a particular piece of code in most IDEs.

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

PR Comment: https://git.openjdk.org/jfx/pull/1630#issuecomment-2463350800

From angorya at openjdk.org  Thu Nov  7 23:10:51 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 23:10:51 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <iN1AEdo6N186ygXUF0R5gUvEA__wklV4txxvAcevg-o=.6f161c98-72e7-4d26-be6c-cf29f86f00c1@github.com>

On Wed, 6 Nov 2024 11:59:10 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 46:
> 
>> 44:      * [ USER_HIGH, handler1, handler2, SKIN_KB, SKIN_LOW, handler3 ]
>> 45:      */
>> 46:     private final ArrayList<Object> items = new ArrayList(4);
> 
> Is there any specific reason as to why initial size is 4 ?  Could use a final constant instead.

no-need, it's the best guesstimate

> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 88:
> 
>> 86:     /**
>> 87:      * Removes all the instances of the specified handler.  Returns true if the list becomes empty as a result.
>> 88:      * Returns true if the list becomes empty as a result of the removal.
> 
> `Returns true if the list becomes empty as a result` :-> This comment is repeated on line 87 and 88. It can be removed from line 87.

that should be fine, even if a bit redundant

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833482018
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833482812

From angorya at openjdk.org  Thu Nov  7 23:26:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 23:26:12 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v38]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <Z2R50lKwrW3CpnJ-rkG4u94ST4TzxWiWIq9KM4Dx0VE=.a99b74d6-079d-4b1e-beab-a8f38e5b49cb@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - readme
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - review comments
 - input map
 - validate model
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - ... and 44 more: https://git.openjdk.org/jfx/compare/3d15a306...7e142dd9

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=37
  Stats: 39757 lines in 206 files changed: 39743 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Thu Nov  7 23:40:29 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 23:40:29 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v39]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <Bws2VQcmqUL_q54W-W75Sk9qOmUlxwiyHgZk_vzPT8s=.55d99574-a30f-4c0e-9f83-f9f016cf1dfe@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/7e142dd9..05f533d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=38
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=37-38

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

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

From angorya at openjdk.org  Thu Nov  7 23:40:30 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Nov 2024 23:40:30 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v37]
In-Reply-To: <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <U7jWEuoaulPcGobHuncexraBDVFe9qUSUCQyIeEpQIo=.67e60085-1f74-43af-a60b-8af91b56a543@github.com>
 <qpELTMACui68UtF2Bn6zI3DeNWyKjGbred8YrPZhDz8=.9ceafa3f-6757-4ce3-aba1-ddc1aaa5d56a@github.com>
Message-ID: <YQCFDd22Sd8DbHVsG3Vx9QYtNnw6CaVFYsz3jV-zZBk=.b118ef8d-8f4d-4e08-a50f-2bc059f69ab6@github.com>

On Wed, 6 Nov 2024 13:43:51 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 pull request now contains 52 commits:
>> 
>>  - readme
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - input map
>>  - validate model
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - javadoc
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - review comments
>>  - measurement node
>>  - ... and 42 more: https://git.openjdk.org/jfx/compare/bd4bc057...a51ae151
>
> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 72:
> 
>> 70:             if (handler != null) {
>> 71:                 insert(++ix, handler);
>> 72:             }
> 
> Is it necessary to store the priority when the handler is `null`. 
> Will it be safe to simply return at beginning of the method when `handler == null` ?

yes, it's important to store the priority.
this is an implementation detail

> modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/PHList.java line 74:
> 
>> 72:             }
>> 73:         } else {
>> 74:             insert(ix, handler);
> 
> Is `if (handler != null)` check required here as well?

yes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833505720
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1833505774

From mfox at openjdk.org  Fri Nov  8 00:37:46 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 8 Nov 2024 00:37:46 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
 <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com>
Message-ID: <Fass8_r-c6qWsqR8xtEuQx4HHL0xW1B4eOVICkfGw0c=.ea76679c-b633-48d3-a567-5e7d15fb418b@github.com>

On Thu, 7 Nov 2024 14:40:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> The failing `SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons` test is a bit odd; it expects that Enter in an **editable** Spinner should result in activating the Default Button. However, a normal TextField doesn't do this either...

Maybe I'm misunderstanding this comment but in my testing pressing Enter in an editable TextField can activate the default button as long as the TextField doesn't have an OnAction handler set. It should not be so easy to block Enter from activating the default button.

It might be helpful to write up a single test that verifies that Enter is handled correctly for TextField, ComboBox, DatePicker, and Spinner. I'm working on a PR to clean up ESC handling and it was useful to write up a single test covering all of these controls. (I want to ensure that the user can always uses ESC to close a modal dialog even if the TextField has a formatter assigned to it. This isn't working currently.)

Why doesn't Spinner work the same as ComboBox? For a ComboBox the client registers the action handler directly on the ComboBox instead of the combo box's editor.

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

PR Comment: https://git.openjdk.org/jfx/pull/1629#issuecomment-2463491419

From mfox at openjdk.org  Fri Nov  8 00:41:47 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 8 Nov 2024 00:41:47 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
 <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com>
Message-ID: <Ncc9VwEaHWNw2ACqzAu_jR6iyairo0-jT7YDI8zp5ok=.c04c2f13-544d-48c8-acc1-5475830d8ee9@github.com>

On Thu, 7 Nov 2024 20:36:50 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This is a proof of concept fix for the linked issue.
>> 
>> We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change default button tests to use non-editable spinner

modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 193:

> 191:             // on arrow keys, moving the cursor unexpectedly.
> 192:             if (!e.isConsumed() && control.isEditable()) {
> 193:                 Event event = textField.getEventDispatcher().dispatchEvent(e.copyFor(textField, textField), new EventDispatchChainImpl());

It would be cleaner to use the exiting `EventUtil.fireEvent()` routine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1629#discussion_r1833545233

From duke at openjdk.org  Fri Nov  8 02:37:44 2024
From: duke at openjdk.org (duke)
Date: Fri, 8 Nov 2024 02:37:44 GMT
Subject: RFR: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass [v3]
In-Reply-To: <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
 <FmkOnwafjX_aoDYGkOdpb9-9M_O1PHWM96rNJ-K3zRE=.a72c4fa9-6197-45a9-b564-13622b619acf@github.com>
Message-ID: <UApkyH-ukhRZ72oZGWiEd8fJVGfoCVTyrtBVE2MxeyM=.efe9a308-99ad-491c-8e9a-2e92240946cc@github.com>

On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
>> 
>> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
>> 
>> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update execute action

@jayathirthrao 
Your change (at version c40554a782cec95fc97bf7a2b886a4a97d8b56af) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1624#issuecomment-2463626100

From jhendrikx at openjdk.org  Fri Nov  8 03:50:48 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 8 Nov 2024 03:50:48 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <Ncc9VwEaHWNw2ACqzAu_jR6iyairo0-jT7YDI8zp5ok=.c04c2f13-544d-48c8-acc1-5475830d8ee9@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
 <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com>
 <Ncc9VwEaHWNw2ACqzAu_jR6iyairo0-jT7YDI8zp5ok=.c04c2f13-544d-48c8-acc1-5475830d8ee9@github.com>
Message-ID: <jV2f_ARvgSkLWGWnEExgy8LfV0ipWiX96ZU3xFcDB6U=.95ded779-c1ad-4051-89ae-f7f477bc5bb5@github.com>

On Fri, 8 Nov 2024 00:39:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change default button tests to use non-editable spinner
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 193:
> 
>> 191:             // on arrow keys, moving the cursor unexpectedly.
>> 192:             if (!e.isConsumed() && control.isEditable()) {
>> 193:                 Event event = textField.getEventDispatcher().dispatchEvent(e.copyFor(textField, textField), new EventDispatchChainImpl());
> 
> It would be cleaner to use the exiting `EventUtil.fireEvent()` routine.

The purpose of doing it this way is to prevent a full dispatch chain (starting from Window/Scene) to be built.  `EventUtil.fireEvent` does something else.  Perhaps a utility method is warranted if this pattern becomes commonplace to solve these kinds of issues.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1629#discussion_r1833658093

From jhendrikx at openjdk.org  Fri Nov  8 03:56:47 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 8 Nov 2024 03:56:47 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <Fass8_r-c6qWsqR8xtEuQx4HHL0xW1B4eOVICkfGw0c=.ea76679c-b633-48d3-a567-5e7d15fb418b@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
 <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com>
 <Fass8_r-c6qWsqR8xtEuQx4HHL0xW1B4eOVICkfGw0c=.ea76679c-b633-48d3-a567-5e7d15fb418b@github.com>
Message-ID: <vA4UMQqAVer1k_br_Gd1kZ5xxzKi8qNWr_EyilC6Yl4=.f972bbd8-ecfc-4eb4-a341-d5a2751d102b@github.com>

On Fri, 8 Nov 2024 00:35:10 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > The failing `SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons` test is a bit odd; it expects that Enter in an **editable** Spinner should result in activating the Default Button. However, a normal TextField doesn't do this either...
> 
> Maybe I'm misunderstanding this comment but in my testing pressing Enter in an editable TextField can activate the default button as long as the TextField doesn't have an OnAction handler set. It should not be so easy to block Enter from activating the default button.

Ah, perhaps that's the problem, I did have an action handler, although it did't consume the event (which normally should mean it's a no-op). Hm...

> It might be helpful to write up a single test that verifies that Enter is handled correctly for TextField, ComboBox, DatePicker, and Spinner. I'm working on a PR to clean up ESC handling and it was useful to write up a single test covering all of these controls. (I want to ensure that the user can always uses ESC to close a modal dialog even if the TextField has a formatter assigned to it. This isn't working currently.)

Yeah, I guess I didn't look deep enough. 
> 
> Why doesn't Spinner work the same as ComboBox? For a ComboBox the client registers the action handler directly on the ComboBox instead of the combo box's editor.

Very good point; when I was looking at the code I was quite confused with the way the editor property works -- it being read only seemed quite useless, except if that's the only way to register an action handler.  It looks suspiciously like a poor design.

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

PR Comment: https://git.openjdk.org/jfx/pull/1629#issuecomment-2463704866

From arapte at openjdk.org  Fri Nov  8 08:38:17 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 8 Nov 2024 08:38:17 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
 <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
Message-ID: <yOoRtc1If5VpDo1SjQ5kNAv7FJvUrfYguKIzuhiTVi0=.1e41c0a0-783e-47ad-8cd0-25ecc3cee239@github.com>

On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
>> 
>> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.
>
> Kevin Rushforth 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 'master' into 8342992-check-sm
>  - 8342992: Security manager check should not use deprecated methods

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1627#pullrequestreview-2423069092

From arapte at openjdk.org  Fri Nov  8 08:38:17 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 8 Nov 2024 08:38:17 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <y3zhLFEuNMKnkps8eAlRmoYLF6Q2etUkZ_-qfRm_2I4=.6dfc5a44-dbe9-4636-937f-cf19c40e8494@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
 <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
 <zwBaiiMPO-sLikwjlCLEVxb_rvfWGdGn4DCD81I2pPY=.884dd641-9160-4fd2-8659-21269aba439e@github.com>
 <y3zhLFEuNMKnkps8eAlRmoYLF6Q2etUkZ_-qfRm_2I4=.6dfc5a44-dbe9-4636-937f-cf19c40e8494@github.com>
Message-ID: <A5Zc90gzeQ12xGL6Ma_gZov6z4KF86DnR2V58WgdmjQ=.5b3396bb-9a63-48c7-996a-762dbfabe44d@github.com>

On Thu, 7 Nov 2024 14:13:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/SecurityUtil.java line 48:
>> 
>>> 46:      * @throws UnsupportedOperationException if the security manager is enabled
>>> 47:      */
>>> 48:     public static void checkSecurityManager() {
>> 
>> Can we cache the results of the check?
>
> I thought about doing that. In fact, I even coded it up, but since it only called at most 4 times (once for each of the 4 call sites) at startup, I wasn't sure it was worth it. I don't mind either way.
> 
> @arapte do you have an opinion?

Given that usage of this method is very limited and it would not change in future. It seems Ok not to cache the result.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1627#discussion_r1833932804

From jdv at openjdk.org  Fri Nov  8 12:30:46 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 8 Nov 2024 12:30:46 GMT
Subject: Integrated: 8342454: Remove calls to doPrivileged in
 javafx.graphics/com.sun.glass
In-Reply-To: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
References: <hVPVyekOO4JLP7tdYPwlGcfuEuajJkg-7O0ER-7upJs=.6ccb5975-f746-4bb1-8187-fdc45facbf4c@github.com>
Message-ID: <oRMoirHVMrDsBdCiP2BcfrHE9_wWvcENOqurPVikq0M=.a9986ea8-592a-4526-b312-a005ec20b319@github.com>

On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This PR removes AccessController.doPrivileged() calls in javafx.graphics/com.sun.glass. It is part of umbrella task [JDK-8342441](https://bugs.openjdk.org/browse/JDK-8342441).
> 
> Also wherever classes are implementing PrivilegedAction they are replaced with java.util.Supplier and get().
> 
> I have removed reference to all AccessControl** class except in `Accessible.java` assuming that AccessControlContext from this class might be needed at some other place and its better if we remove it under [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993)

This pull request has now been integrated.

Changeset: 4213db7c
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4213db7c2b5c1fe4e58cda969a420fc2c02f5ab1
Stats:     450 lines in 35 files changed: 16 ins; 263 del; 171 mod

8342454: Remove calls to doPrivileged in javafx.graphics/com.sun.glass

Reviewed-by: kcr, lkostyra, jvos

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

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

From jhendrikx at openjdk.org  Fri Nov  8 12:50:47 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 8 Nov 2024 12:50:47 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
Message-ID: <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>

On Wed, 11 Dec 2019 12:26:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
>> 
>> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix.
>> 
>> There are additional/changed tests to verify the fix. All old tests are passing.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added tests to guard against JDK-8145515

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 190:

> 188:         if (onAction != null || actionEvent.isConsumed()) {
> 189:             event.consume();
> 190:         }

@kleopatra @kevinrushforth @aghaisas 

Shouldn't this be an `&&` ?  Now having an empty `setOnAction` that doesn't consume anything (but just logs for example) will affect the operation of this control.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1834354878

From kevin.rushforth at oracle.com  Fri Nov  8 13:46:53 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 Nov 2024 05:46:53 -0800
Subject: CFV: New OpenJFX Committer: Jayathirth D V
Message-ID: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>

I hereby nominate Jayathirth D V [1] to OpenJFX Committer.

Jay is a member of the JavaFX team at Oracle who has contributed 12 
commits [2] to OpenJFX. He has contributed an additional 5 commits to 
the OpenJFX jfx-tests repo [3].

Votes are due by November 22, 2024 at 14:00 UTC.

Only current OpenJFX Committers [4] 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 [5]. Nomination to a project 
Committer is described in [6].

Thanks.

-- Kevin


[1] https://openjdk.org/census#jdv

[2] 
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Jayathirth%22&type=commits

[3] 
https://github.com/search?q=repo%3Aopenjdk%2Fjfx-tests+author-name%3A%22Jayathirth%22&type=commits

[4] https://openjdk.org/census#openjfx

[5] https://openjdk.org/bylaws#lazy-consensus

[6] https://openjdk.org/projects#project-committer


From kevin.rushforth at oracle.com  Fri Nov  8 13:48:06 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 Nov 2024 05:48:06 -0800
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <652e1c42-7734-4661-8ab7-1759c6b2d799@oracle.com>

Vote: YES

-- Kevin

On 11/8/2024 5:46 AM, Kevin Rushforth wrote:
> I hereby nominate Jayathirth D V [1] to OpenJFX Committer.


From nlisker at gmail.com  Fri Nov  8 14:05:18 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 8 Nov 2024 16:05:18 +0200
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <652e1c42-7734-4661-8ab7-1759c6b2d799@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
 <652e1c42-7734-4661-8ab7-1759c6b2d799@oracle.com>
Message-ID: <CA+0ynh8ygP9c6YZ8CGAqy5g_Wb-L4iD5pLpBSbe=cKQHO0GHYw@mail.gmail.com>

Vote: YES

On Fri, Nov 8, 2024 at 3:48?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Vote: YES
>
> -- Kevin
>
> On 11/8/2024 5:46 AM, Kevin Rushforth wrote:
> > I hereby nominate Jayathirth D V [1] to OpenJFX Committer.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241108/743eb490/attachment-0001.htm>

From duke at openjdk.org  Fri Nov  8 14:17:10 2024
From: duke at openjdk.org (Daniel Godino)
Date: Fri, 8 Nov 2024 14:17:10 GMT
Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and
 pseudo-class in style sheet [v10]
In-Reply-To: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com>
Message-ID: <RaI8hFIBUfDhOLmv74nFPEthd43zNFwXxgNL_vgDGgE=.51776c2f-fa07-4591-bcc0-83a46863462e@github.com>

On Tue, 12 Sep 2023 23:28:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
>> 
>> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
>> 
>> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
>> 
>> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well.
>> 
>> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
>> 
>> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
>> 
>> Although the test case above was extreme, this change should have positive effects for most applications.
>
> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate
>  - Use standard asserts in test
>  - Add copyright header
>  - Merge branch 'master' of https://git.openjdk.org/jfx into
>    feature/immutable-pseudoclassstate
>  - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate
>  - Avoid using Lambda in ImmutablePseudoClassSetsCache.of()
>  - Merge branch 'master' of https://git.openjdk.org/jfx into
>    feature/immutable-pseudoclassstate
>  - Fix another edge case in BitSet equals
>    
>    When arrays are not the same size, but there are no set bits in the ones
>    the other set doesn't have, two bit sets can still be considered equal
>  - Take element type into account for BitSet.equals()
>  - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray
>    
>    - Removed faulty toArray implementations in PseudoClassState and
>    StyleClassSet
>    - Added test that verifies equals/hashCode for PseudoClassState respect
>    Set contract now
>    - Made getBits package private so it can't be inherited
>  - ... and 9 more: https://git.openjdk.org/jfx/compare/624fe86f...962c43ea

Hi,

Sorry for the delay in my response, I understand the policy and makes sense waiting for the next LTS, thank you @johanvos.

@hjohn About how this is helping my application, it is a data intense app using tables, these tables have css changes  based on the state of the table, the rows on the table receive multiple changes in its data for some time, so around 100 rows are updating data every second, a few months ago I migrated the app from javafx 8 to javafx 21.03, now I am having memory issues when the app is used for a long time, I've been looking for memory leaks, on a heap dump  I saw a difference between running the app for 8 hours and starting fresh on a few JavaFx Objects:

com.sun.javafx.css.PseudoClassState +444MB around 18 million instances extra
com.sun.javafx.css.CalculatedValue +140MB 5 million extra instances

 Looking for information about these objects I found this PR, I've done some tests and the use of JavaFx 22.0.2 seems to be helping but I cannot give you the exact same data to compare how much of the 444MB is exactly reduced.
 
 I've compared the app vs when we were using javafx 8 and seems to consume less memoty with java 8 but other changes done in the app do not allow me to stress the application so much so it is not a fair comparision.
 
 Thank you very much for your quick responses, really appreciated.

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

PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-2464864221

From john at status6.com  Fri Nov  8 15:18:16 2024
From: john at status6.com (John Neffenger)
Date: Fri, 8 Nov 2024 07:18:16 -0800
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <d8893c91-78d2-438f-8293-2add7f0d839a@status6.com>

Vote: YES

John

On 11/8/24 5:46 AM, Kevin Rushforth wrote:
> I hereby nominate Jayathirth D V [1] to OpenJFX Committer.


From andy.goryachev at oracle.com  Fri Nov  8 15:26:19 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 8 Nov 2024 15:26:19 +0000
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <DS0PR10MB62002B8F88331B5D6C0874DFE55D2@DS0PR10MB6200.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: Friday, November 8, 2024 at 05:47
To: openjfx-dev <openjfx-dev at openjdk.org>, Jayathirth Rao Daarapuram Venkatesh Murthy <jayathirth.d.v at oracle.com>
Subject: CFV: New OpenJFX Committer: Jayathirth D V
I hereby nominate Jayathirth D V [1] to OpenJFX Committer.

Jay is a member of the JavaFX team at Oracle who has contributed 12
commits [2] to OpenJFX. He has contributed an additional 5 commits to
the OpenJFX jfx-tests repo [3].

Votes are due by November 22, 2024 at 14:00 UTC.

Only current OpenJFX Committers [4] 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 [5]. Nomination to a project
Committer is described in [6].

Thanks.

-- Kevin


[1] https://openjdk.org/census#jdv

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Jayathirth%22&type=commits

[3]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx-tests+author-name%3A%22Jayathirth%22&type=commits

[4] https://openjdk.org/census#openjfx

[5] https://openjdk.org/bylaws#lazy-consensus

[6] https://openjdk.org/projects#project-committer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241108/3885838d/attachment-0001.htm>

From angorya at openjdk.org  Fri Nov  8 15:34:19 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 8 Nov 2024 15:34:19 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
Message-ID: <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>

On Fri, 8 Nov 2024 12:48:45 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added tests to guard against JDK-8145515
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 190:
> 
>> 188:         if (onAction != null || actionEvent.isConsumed()) {
>> 189:             event.consume();
>> 190:         }
> 
> @kleopatra @kevinrushforth @aghaisas 
> 
> Shouldn't this be an `&&` ?  Now having an empty `setOnAction` that doesn't consume anything (but just logs for example) will affect the operation of this control.

correct, it's a bug.
#1523

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1834587435

From lukasz.kostyra at oracle.com  Fri Nov  8 15:41:52 2024
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 8 Nov 2024 15:41:52 +0000
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <SN7PR10MB6955267671A9C44D03B3D7D7FE5D2@SN7PR10MB6955.namprd10.prod.outlook.com>

?
?Vote: YES

Lukasz

On 11/8/2024 5:46 AM, Kevin Rushforth wrote:
> I hereby nominate Jayathirth D V [1] to OpenJFX Committer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241108/5c559b53/attachment.htm>

From fastegal at openjdk.org  Fri Nov  8 15:43:36 2024
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Fri, 8 Nov 2024 15:43:36 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
Message-ID: <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>

On Fri, 8 Nov 2024 15:31:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 190:
>> 
>>> 188:         if (onAction != null || actionEvent.isConsumed()) {
>>> 189:             event.consume();
>>> 190:         }
>> 
>> @kleopatra @kevinrushforth @aghaisas 
>> 
>> Shouldn't this be an `&&` ?  Now having an empty `setOnAction` that doesn't consume anything (but just logs for example) will affect the operation of this control.
>
> correct, it's a bug.
> #1523

hmm .. it's been a while but you might be on to something. 

Let's recap:

- the first issue to get fixed was JDK-8207774: the problem was that the isConsumed always was false (due to creating the actionEvent for passing around was done by the constructor that led to immediate copying, setting consumed to false)
- the next issue was this: the problem was that actively refiring the keyEvent on parent led to a nested eventDispatch, confusing every collaborator. That was fixed by removing the refire altogether and consuming the keyEvent if handled by the textField's action/Listeners (that's the plainly reverted logic above)
- both before and after the fixes the state "handled" can be reached by the mere existence of an onAction handler on the textField, consuming or not

And that's still wrong, as you correctly - IMO - noted. The expectation formulated as a test (c&p and adjusted from TextFieldTest)

    /**
     * ENTER must be forwarded if action
     * not consumed the action.
     *
     * Here we test that key handlers on parent are notified.
     */
    @Test
    public void testEnterWithNotConsumingActionParentHandler() {
        initStage();
        root.getChildren().add(txtField);
        txtField.setOnAction(e -> {}); // do nothing handler
        List<KeyEvent> keys = new ArrayList<>();

        root.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
            keys.add(e);
        });
        stage.show();
        KeyEventFirer keyboard = new KeyEventFirer(txtField);
        keyboard.doKeyPress(ENTER);
        assertEquals("key handler must be notified", 1, keys.size());
    }

We can't reach that by replacing the || by && (would introduce a regression, as failing tests indicate) but .. maybe by entirely removing the not/null check of onAction: the fired actionEvent will be passed to the singleton handler (along with any added via addXX) anyway, so it doesn't really make sense (with the first issue fixed)

Now the method looks like and all tests including the new one above (and hopefully the analogous twins of XXConsuming -> XXNotConsuming, didn't try, being lazy ;):

    @Override protected void fire(KeyEvent event) {
        TextField textField = getNode();
        EventHandler<ActionEvent> onAction = textField.getOnAction();
        // use textField as target to prevent immediate copy in dispatch
        ActionEvent actionEvent = new ActionEvent(textField, textField);

        textField.commitValue();
        textField.fireEvent(actionEvent);
        if (actionEvent.isConsumed()) {
            event.consume();
        }
    }

What do you think? My code brain is a bit rusty, so might have missed something.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1834601110

From angorya at openjdk.org  Fri Nov  8 15:51:29 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 8 Nov 2024 15:51:29 GMT
Subject: RFR: 8342992: Security manager check should not use deprecated
 methods [v2]
In-Reply-To: <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
 <qeohYSIs3Uh8UrAymo5dsViveGyXCCh9BWpxFlH4YH8=.5d40f3cf-8f76-4139-87fb-064ccf9c1540@github.com>
Message-ID: <4EkzA7YFSMo9HJaQUW0LHGL_bLeI1mfgV73NESjD3xM=.67ffe374-4484-466e-9cef-7c5cac22b76e@github.com>

On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
>> 
>> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.
>
> Kevin Rushforth 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 'master' into 8342992-check-sm
>  - 8342992: Security manager check should not use deprecated methods

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1627#pullrequestreview-2424150989

From kcr at openjdk.org  Fri Nov  8 16:31:34 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 16:31:34 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
Message-ID: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>

On Fri, 8 Nov 2024 15:39:57 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java line 190:
>> 
>>> 188:         if (onAction != null || actionEvent.isConsumed()) {
>>> 189:             event.consume();
>>> 190:         }
>> 
>> @kleopatra @kevinrushforth @aghaisas 
>> 
>> Shouldn't this be an `&&` ?  Now having an empty `setOnAction` that doesn't consume anything (but just logs for example) will affect the operation of this control.
>
> @hjohn  @kevinrushforth @aghaisas
> 
> hmm .. it's been a while but you might be on to something. 
> 
> Let's recap:
> 
> - the first issue to get fixed was JDK-8207774: the problem was that the isConsumed always was false (due to creating the actionEvent for passing around was done by the constructor that led to immediate copying, setting consumed to false)
> - the next issue was this: the problem was that actively refiring the keyEvent on parent led to a nested eventDispatch, confusing every collaborator. That was fixed by removing the refire altogether and consuming the keyEvent if handled by the textField's action/Listeners (that's the plainly reverted logic above)
> - both before and after the fixes the state "handled" can be reached by the mere existence of an onAction handler on the textField, consuming or not
> 
> And that's still wrong, as you correctly - IMO - noted. The expectation formulated as a test (c&p and adjusted from TextFieldTest)
> 
>     /**
>      * ENTER must be forwarded if action
>      * not consumed the action.
>      *
>      * Here we test that key handlers on parent are notified.
>      */
>     @Test
>     public void testEnterWithNotConsumingActionParentHandler() {
>         initStage();
>         root.getChildren().add(txtField);
>         txtField.setOnAction(e -> {}); // do nothing handler
>         List<KeyEvent> keys = new ArrayList<>();
> 
>         root.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
>             keys.add(e);
>         });
>         stage.show();
>         KeyEventFirer keyboard = new KeyEventFirer(txtField);
>         keyboard.doKeyPress(ENTER);
>         assertEquals("key handler must be notified", 1, keys.size());
>     }
> 
> We can't reach that by replacing the || by && (would introduce a regression, as failing tests indicate) but .. maybe by entirely removing the not/null check of onAction: the fired actionEvent will be passed to the singleton handler (along with any added via addXX) anyway, so it doesn't really make sense (with the first issue fixed)
> 
> Now the method looks like and all tests including the new one above (and hopefully the analogous twins of XXConsuming -> XXNotConsuming, didn't try, being lazy ;):
> 
>     @Override protected void fire(KeyEvent event) {
>         TextField textField = getNode();
>         EventHandler<ActionEvent> onAction = textField.getOnAction();
>         // JDK-8207774
>         // use textField as target to prevent immediate copy in dispatch
>         ActionEvent actionEvent = new ActionEvent(textField, textField);
> 
>         textField.comm...

@kleopatra Your explanation makes sense to me. Thank you for taking the time to write it up.

If so, the proposed fix, including adjusting the comment, would be:


--- a/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
+++ b/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
@@ -162,9 +162,8 @@ public class TextFieldBehavior extends TextInputControlBehavior<TextField> {

         textField.commitValue();
         textField.fireEvent(actionEvent);
-        // fix of JDK-8207759: reverted logic
-        // mapping not auto-consume and consume if handled by action
-        if (onAction != null || actionEvent.isConsumed()) {
+        // Consume the original event if the copied actionEvent was consumed.
+        if (actionEvent.isConsumed()) {
             event.consume();
         }
     }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1834693101

From jbhaskar at openjdk.org  Fri Nov  8 16:55:55 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 8 Nov 2024 16:55:55 GMT
Subject: RFR: 8343630: Pass AccessControlContext to/from WebKit as opaque
 object
In-Reply-To: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
Message-ID: <j3V-qUpkoczci0ZH69lXMk6y_uJQ2Qk_VnSeR261XfI=.a7db89dd-3285-4e7f-b664-b891b095a108@github.com>

On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.
> 
> As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:
> 
> 1. It will minimize the changes to native WebKit JNI code.
> 2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.
> 
> This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).
> 
> NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

Looks good to me , tested via an example.

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1626#pullrequestreview-2424364177

From kcr at openjdk.org  Fri Nov  8 17:01:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 17:01:14 GMT
Subject: Integrated: 8343630: Pass AccessControlContext to/from WebKit as
 opaque object
In-Reply-To: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
References: <_GvPdcbOU72yfk8X7RkUuMmShrs5qXHHnkwjAPSqKdU=.da7d9ea4-13af-4aa5-ab26-62763948e2c8@github.com>
Message-ID: <AM8Rq9d2hIeGqB5qYhJxWytfk5aa8VJIMCzKUgiQcbA=.1fd3fb2b-8ce0-434c-8b34-3e361e06dfb1@github.com>

On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR modifies the signature of four methods -- 3 `native` JNI methods and 1 Java method that is called from native code using JNI -- changing the type of one of the arguments from `AccessControlContext` to `Object`.
> 
> As a follow-on to removing security manager support, we are removing all references to the terminally deprecated AccessController and AccessControlConext classes, which is tracked by [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993).
> 
> The Java code passes an `AccessControlContext` instance to the native `JSObject` code, which stores it in the object so that it can later pass it back to the `Utilities::fwkInvokeWithContext` Java method via a JNI upcall. The native WebKit otherwise does not use the `AccessControlConext` object. Since it is already treated as an opaque object by the native code, the easiest path to eliminating the references to `AccessControlConext` is to change the method signatures to pass an `Object` rather than `AccessControlConext`. This has two related advantages:
> 
> 1. It will minimize the changes to native WebKit JNI code.
> 2. It will allow us to keep the native code identical between mainline jfx24 and earlier releases (e.g., jfx23u, jfx21u, etc), since earlier releases still need to be able to run with a security manager.
> 
> This bug fix needs to go in ahead of the fix for[JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993) and will be be backported to all earlier code lines (whereas none of the other SM follow-up fixes can be backported).
> 
> NOTE: Both this PR and PR #1620 touch the `Utilities::fwkInvokeWithContext` method. I did my fix in such a way that the two PRs can go in in either order with no conflicts. By doing it this way, it can be backported cleanly to earlier code lines. Consequently, after both PRs are integrated, there will be an unused local variable that can be removed. I will remove that as part of [JDK-8342993](https://bugs.openjdk.org/browse/JDK-8342993), along with the then-unneeded `SuppressWarnings` and unused `AccessController` import.

This pull request has now been integrated.

Changeset: fffa0fc4
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/fffa0fc4fd0f2ac332ae616066579c3b6b5a9861
Stats:     8 lines in 3 files changed: 2 ins; 1 del; 5 mod

8343630: Pass AccessControlContext to/from WebKit as opaque object

Reviewed-by: angorya, jbhaskar

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

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

From kcr at openjdk.org  Fri Nov  8 17:02:18 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 17:02:18 GMT
Subject: Integrated: 8342992: Security manager check should not use deprecated
 methods
In-Reply-To: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
References: <gOqAWRttndNB9ER8qlDrZmhKVkti5YwvBL9dsH73AR4=.420562fe-0ce4-4f5e-83cb-64d23c58488b@github.com>
Message-ID: <j2Ea-eahqsZl_HAMMGp_YSSKSbz8mRlCX1EcboqMjTE=.6c7a7eec-ad50-49dd-8ddb-48609786c0d6@github.com>

On Tue, 5 Nov 2024 19:37:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> As specified in the security manager removal CSR, [JDK-8341858](https://bugs.openjdk.org/browse/JDK-8341858), JavaFX now checks at startup whether the security manager is enabled and fails fast with an `UnsupportedOperationException` if it is. The check is currently done in the `<clinit>` methods of `PlatformImpl` and `LauncherImpl` by calling the deprecated `System::getSecurityManager` method.
> 
> This PR creates a new `SecurityUtility::checkSecurityManager` utility method in `javafx.base` that uses reflection to avoid calling API that is deprecated for removal. I also added a call to `checkSecurityManager` in `ReflectUtil` and `MethodUtil` in `javafx.base` for non-graphical applications that only use `javafx.base`.

This pull request has now been integrated.

Changeset: 5ac5009d
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5ac5009deed0e9c72683a936b26a5c8b081ac58e
Stats:     89 lines in 5 files changed: 77 ins; 8 del; 4 mod

8342992: Security manager check should not use deprecated methods

Reviewed-by: arapte, angorya

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

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

From kcr at openjdk.org  Fri Nov  8 18:00:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 18:00:47 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v5]
In-Reply-To: <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
Message-ID: <XV6M4uKwXnN2Ldp-O8kzIMEhvPc46z4rXcYO3Dujt6w=.7055967d-4293-4ed2-bb69-7d1fb2351fb4@github.com>

On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   focus visible

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1628#pullrequestreview-2424559117

From kcr at openjdk.org  Fri Nov  8 19:16:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 19:16:35 GMT
Subject: Integrated: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14
 which will be removed
In-Reply-To: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
References: <dBt9VYrBeJHYowhT4lA7hldMQ5kLlOyrCcKMalsN9ZE=.011bc9ab-5e0f-43cf-add3-9f0a265af6ab@github.com>
Message-ID: <msP5OKHGoAISOPCP-zbDyAJG--QPaeI70ojUvGQ2OUA=.7c2bb620-913b-4180-8bc2-c1eed9990240@github.com>

On Thu, 7 Nov 2024 19:29:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Fix the GHA build on macOS / aarch64, which uses a macOS 14 GitHub Actions runner, by using the default Xcode 15 rather than explicitly selecting Xcode 14.
> 
> GitHub has announced the removal of Xcode 14 from their macOS 14 images. See the following pages:
> 
> https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md
> https://github.com/actions/runner-images/issues/10703
> 
> The following build failed, suggesting that they may have done this already:
> 
> https://github.com/jayathirthrao/jfx/actions/runs/11718276557/job/32639337526
> 
> At least one other build has failed as well. Subsequent builds passed, so they might be rolling it out incrementally, but in any case, we need to stop relying on using Xcode 14 on macOS 14.

This pull request has now been integrated.

Changeset: d0011b21
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d0011b21959abdcc0ee9c969e7bd5fbbccb5d4ce
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which will be removed

Reviewed-by: angorya

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

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

From tobias.oelgarte at gmail.com  Fri Nov  8 20:46:45 2024
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Fri, 8 Nov 2024 21:46:45 +0100
Subject: Prioritized event handlers
In-Reply-To: <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
 <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <d7282fbf-98d4-41ea-8f20-ae4eb8885332@gmail.com>

This whole situation reminds me very much of Shadow DOM [1], an approach 
for components (controls/skins) with a complex internal structure that 
should not be visible from the outside. The handling of events could 
serve as a template here. [2]

[1] 
https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
[2] https://pm.dartus.fr/posts/2021/shadow-dom-and-event-propagation/

On 07.11.24 20:06, Andy Goryachev wrote:
>
> > 4. The target allows you to register the same event handler instance 
> multiple times on multiple different controls without having to create 
> a new lambda each time that knows which control (target) it is for. It 
> has a similar function to the Observable parameter in 
> InvalidationListeners and ChangeListeners.? In effect, having the 
> Target will also make it possible in the future to share a single 
> input map with all controls of the same type (currently there is a ton 
> of memory being wasted here duplicating input maps, especially for 
> controls with large input maps like TextFields).
>
> This is a very strange rationale, in my opinion.? And why talk about 
> Controls when the Event.copyFor() is at the very fundamental level?? 
> To me, this severely complicates everything, including breaking 
> isConsumed() logic.? Sending events that are not designed to bubble up 
> seems to run contrary to the whole event dispatching idea.? Are you 
> trying to explain the current implementation?? Swing never needed to 
> store the target in the event, and it works just fine.
>
> This brings me to another problem I am struggling with: why expose the 
> event dispatchers??? This should have never been done, in my opinion.? 
> Swing's FwDispatcher is an implementation detail.? But instead, we 
> seem to be dealing with unnecessarily increased complexity, including 
> misbehaving EventDispatcher implementations.
>
> May be it's just me, I don't see the beauty of this thing.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John 
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Thursday, November 7, 2024 at 05:35
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Prioritized event handlers
>
> Hi Andy,
>
> Simply replacing a Skin can change the order of event handlers.? In 
> other words, if you registered your handler **after** the control was 
> shown, then replace its Skin (which can be done by CSS state changes), 
> then your handler is now called before the Skin/Behavior handlers.? 
> Also removing your own handlers, then installing them back (in the 
> same order) will not lead to the same result either.? The culprit is 
> simply that two different parties (FX and the User) are sharing the 
> same system -- this is mostly fine for properties, but Events are 
> stateful, and so the processing order matters.
>
> I've given this quite a lot of thought recently, and I also looked at 
> the Spinner problem, and I think I do have an all encompassing 
> solution for both the ordering problem and the Spinner problem.
>
> Observations:
>
> Controls have some trouble keeping their Skin internals hidden from 
> the outside world.? For the user, the Spinner is a black box; it is 
> the thing that gets the focus and accepts input, even though the 
> actual implementation may be delegating this to an internal component 
> (in the case of the default SpinnerSkin, a FakeFocusTextField -- a 
> detail that you can see "leaking" out when registering a listener on 
> Scene#focusOwner).
>
> Secondly, because Skins are re-using normal controls, which only work 
> when focused, they sometimes have to "fake" the focus (this is a 
> problem I won't be solving in this post).? IMHO however, this should 
> be handled differently altogether, perhaps with some kind of focus 
> delegation mechanism as part of Behaviors -- the user observable focus 
> should IMHO always be the Control, as it is a black box.? The current 
> fake focus implementation tries to keep this hidden (by not firing 
> change listeners) which is incredibly dubious, and also fails (you can 
> still see internals being focused with Scene#focusOwner).
>
> Analysis:
>
> Inside SpinnerSkin, there is a lot of jumping through hoops?in the 
> form of filtering events, copying them, and being aware of what the 
> Behavior needs (SpinnerSkin for example knows that the Behavior has 
> need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this 
> jumping through hoops is to make the internal TextField component 
> receive events, but at the same time, not confusing the Behavior with 
> duplicated events (as the Behavior handlers are in between the event 
> root (the window) and the target (the internal textfield) events flow 
> past the Behavior's handlers).
>
> Solution:
>
> The Behavior event handlers are at the Control level -- as far as the 
> user is concerned, this is the target and also final destination 
> (there is nothing deeper).? In effect you could say that the Behavior 
> could register either a Filter or a Handler, and the result would be 
> the same -- filtering down from Scene -> Node -> Spinner and then 
> bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the 
> Behavior registers a filter or a handler as they're at the same 
> position (of course there are some small differences, but I think we 
> actually WANT filters in behaviors, more on this later).
>
> One of the problems is that the event handlers in the behavior trigger 
> **after** the internal TextField -- but we have the perfect mechanism 
> to swap this around; if the Behavior registered a filter (which as I 
> said earlier is sort of at the same position conceptually) then it 
> would trigger **before** the internal TextField.? Spinner is then free 
> to process and consume the arrow keys it needs, and the Skin would not 
> need to be aware of this (ie. if a different Behavior decides to 
> consume the +/- keys, then it would work with the current Skin).? The 
> Skin then just forwards any events that arrive at the Control level 
> still (everything minus potential arrow keys consumed by the Behavior) 
> to the internal text field.
>
> The second part of this solution relates to how to get Events to go 
> down to the internal TextField.? Events are fired at the current focus 
> owner, which is the Control. The TextField only has fake focus.? So we 
> need to take events that arrive at the Control, copy them and send 
> them to the internal TextField.? However, there is a small problem -- 
> the standard event mechanism will make such copies filter down from 
> Window level all the way to the TextField level (passing the Spinner 
> control).? But this isn't want we want at all.? Spinner is a black 
> box; when we want to fire an event into the internals, we don't want 
> this event to be exposed either (aside from the problems that causes, 
> with having to be careful not to copy the event again as it will pass 
> your forwarding handler again).? In effect, we want a different event 
> dispatch hierarchy that is limited to the Control only. So, why not 
> build a dispatch chain that exclusively targets the internals?? This 
> chain in this case only consists of one EventDispatcher, the one from 
> the internal TextField.? The event copy is fired at it and the control 
> works as expected.? It automatically also solves the "ENTER" problem 
> described in https://bugs.openjdk.org/browse/JDK-8337246 without 
> further hacks.
>
> Takeaways:
>
> I now think Behaviors should always be doing their event handling in 
> filters, for the simple reason that they should get to act first 
> before the Skin gets to act on an event;?events arriving at the 
> Control level which is the final destination can be handled by either 
> a handler or a filter and there would be no discernible difference.? 
> Not only does this solve the problem with the internal text field and 
> the Skin needing to be aware of what keys Behavior will be handling, 
> but it also then makes behaviors always act before user event 
> handlers, creating consistency here (ie. replacing a Skin will not 
> affect event handler order).? This frees up handlers for user 
> purposes.? The ordering problem moves to the filters, so we may still 
> want to do a solution here (see below).
>
> Event handler order when Skins get re-added:
>
> Handlers registered by users can change order with regards to handlers 
> registered by Behaviors when the Skin change or depending on when the 
> user registered their handlers.? This is problematic for events as 
> they are stateful and can be consumed, and so an order change can lead 
> to a functionality change. This is not user friendly, as the user 
> expects that the event handler and filter infrastructure is for their 
> use alone.? I can see a few things we could explore further:
>
> - See if it is possible to add some internal API that allows Behaviors 
> to register filters or handlers first/last -- note that "last" here 
> means **always** last, even when user handlers are added later (first 
> would be an easier option).
> - See if it is possible to change how `buildEventDispatchChain` works 
> for Controls to include another dispatcher level exclusively for 
> Behaviors. Where a standard chain would look like 
> Window->Scene->Nodes->Control, it would become 
> Window->Scene->Nodes->Control->Behavior(private) -- as this is a 
> completely separate level, handlers from users and behaviors cannot 
> become intertwined and so there will always be a predictable ordering
>
> On 07/11/2024 01:03, Andy Goryachev wrote:
>
>     Dear Michael:
>
>     What happened to this proposal?? I would like to restart the
>     discussion, if possible.
>
>     More specifically, I would like to discuss the following topics:
>
>      1. the reason the discussion was started was due to "priority
>         inversion" problem in Controls/Skins, ex.: JDK-8231245
>         <https://bugs.openjdk.org/browse/JDK-8231245>?Controls'
>         behavior must not depend on sequence of handler registration.?
>         Do we have this problem elsewhere?? In other words, does it
>         make sense to change the API at the EventDispatcher level when
>         the problem can be easily solved by the InputMap at the
>         Control level?
>      2. dispatching of events that have been consumed (as mentioned in
>         the earlier discussion)
>      3. problem of creating unnecessary clones of events via
>         Event.copyFor(), leading to ex.: JDK-8337246
>         <https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does
>         not consume ENTER KeyEvent when editor ActionEvent is consumed
>      4. why do we need Event.copyFor() in the first place?why does
>         Event contain the target??
>
> 1. You would have the same problem with other events that Behaviors 
> listen to (ie. mouse events), or events they handle without going 
> through the input map (TYPED, RELEASED), or events they handle with a 
> parent event type (all KeyEvents, not a specific one).
>
> 2. This is IMHO a bug, it only happens for the same event type at one 
> level, it should simply be fixed
>
> 3. See above, but in short, I think the problem is not the event 
> clones, but the fact that these clones are traversing the entire 
> Window->Scene->Node hierarchy.? Events with a restricted hierarchy 
> solve this.
>
> 4. The target allows you to register the same event handler instance 
> multiple times on multiple different controls without having to create 
> a new lambda each time that knows which control (target) it is for. It 
> has a similar function to the Observable parameter in 
> InvalidationListeners and ChangeListeners.? In effect, having the 
> Target will also make it possible in the future to share a single 
> input map with all controls of the same type (currently there is a ton 
> of memory being wasted here duplicating input maps, especially for 
> controls with large input maps like TextFields).
>
> --John
>
>     Too many topics, yes, we might want to split the discussion into
>     separate threads.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau?
>     <michaelstrau2 at gmail.com> <mailto:michaelstrau2 at gmail.com>
>     *Date: *Friday, October 27, 2023 at 19:41
>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: Prioritized event handlers
>
>     Here is the proposal:
>     https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
>
>     Comments are welcome.
>
>
>     On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
>     <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>     >
>     > Would it be possible to create a proposal in the JEP format
>     outlining the proposed public API?
>     >
>     >
>     >
>     > Thank you
>     >
>     > -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241108/6edbcaab/attachment-0001.htm>

From jhendrikx at openjdk.org  Fri Nov  8 20:49:15 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 8 Nov 2024 20:49:15 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
 <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
Message-ID: <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>

On Fri, 8 Nov 2024 16:28:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @hjohn  @kevinrushforth @aghaisas
>> 
>> hmm .. it's been a while but you might be on to something. 
>> 
>> Let's recap:
>> 
>> - the first issue to get fixed was JDK-8207774: the problem was that the isConsumed always was false (due to creating the actionEvent for passing around was done by the constructor that led to immediate copying, setting consumed to false)
>> - the next issue was this: the problem was that actively refiring the keyEvent on parent led to a nested eventDispatch, confusing every collaborator. That was fixed by removing the refire altogether and consuming the keyEvent if handled by the textField's action/Listeners (that's the plainly reverted logic above)
>> - both before and after the fixes the state "handled" can be reached by the mere existence of an onAction handler on the textField, consuming or not
>> 
>> And that's still wrong, as you correctly - IMO - noted. The expectation formulated as a test (c&p and adjusted from TextFieldTest)
>> 
>>     /**
>>      * ENTER must be forwarded if action
>>      * not consumed the action.
>>      *
>>      * Here we test that key handlers on parent are notified.
>>      */
>>     @Test
>>     public void testEnterWithNotConsumingActionParentHandler() {
>>         initStage();
>>         root.getChildren().add(txtField);
>>         txtField.setOnAction(e -> {}); // do nothing handler
>>         List<KeyEvent> keys = new ArrayList<>();
>> 
>>         root.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
>>             keys.add(e);
>>         });
>>         stage.show();
>>         KeyEventFirer keyboard = new KeyEventFirer(txtField);
>>         keyboard.doKeyPress(ENTER);
>>         assertEquals("key handler must be notified", 1, keys.size());
>>     }
>> 
>> We can't reach that by replacing the || by && (would introduce a regression, as failing tests indicate) but .. maybe by entirely removing the not/null check of onAction: the fired actionEvent will be passed to the singleton handler (along with any added via addXX) anyway, so it doesn't really make sense (with the first issue fixed)
>> 
>> Now the method looks like and all tests including the new one above (and hopefully the analogous twins of XXConsuming -> XXNotConsuming, didn't try, being lazy ;):
>> 
>>     @Override protected void fire(KeyEvent event) {
>>         TextField textField = getNode();
>>         EventHandler<ActionEvent> onAction = textField.getOnAction();
>>         // JDK-8207774
>>         // use textField as target to prevent immediate copy in dispatch
>>         ...
>
> @kleopatra Your explanation makes sense to me. Thank you for taking the time to write it up.
> 
> If so, the proposed fix, including adjusting the comment, would be:
> 
> 
> --- a/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
> +++ b/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
> @@ -162,9 +162,8 @@ public class TextFieldBehavior extends TextInputControlBehavior<TextField> {
> 
>          textField.commitValue();
>          textField.fireEvent(actionEvent);
> -        // fix of JDK-8207759: reverted logic
> -        // mapping not auto-consume and consume if handled by action
> -        if (onAction != null || actionEvent.isConsumed()) {
> +        // Consume the original event if the copied actionEvent was consumed.
> +        if (actionEvent.isConsumed()) {
>              event.consume();
>          }
>      }

You are right, `&&` would be insufficient as there is another way to add action handlers.  I didn't really see that, although the fix I had in mind was to eliminate the `onAction` variable completely (it is unused in your fix as well), so probably would have ended up at the correct result :)

I can roll this into a small PR if you wish.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1835039351

From kcr at openjdk.org  Fri Nov  8 21:19:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 21:19:12 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v18]
In-Reply-To: <IZ0wHztUgrUTz0EL76PQURjh0RdnAadX6DOgEH82y-4=.f4f579c7-a2c6-4402-b646-17cba2b6b398@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <IZ0wHztUgrUTz0EL76PQURjh0RdnAadX6DOgEH82y-4=.f4f579c7-a2c6-4402-b646-17cba2b6b398@github.com>
Message-ID: <TFAG7Gb2oeeoJGX83_rAvr1YjZkfT7vIU0hBcyYIkkA=.4920f482-a09c-4021-b289-ab8ae5c5eb2e@github.com>

On Thu, 7 Nov 2024 19:04:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move automatically added imports
>  - rename test...javax -> test...java2d

> This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.

I have a patch for our closed test that I've been using for testing. I ran a Jenkins headful test job and with that (closed) patch + the latest patch in this PR and all looks good.

I've looked over most of the code changes and it all looks good. I'll finish up next week.

@johanvos might want to review the changes in `IosImageLoader.java`

modules/javafx.graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoader2.java line 316:

> 314:                         : ImageStorage.ImageType.RGB;
> 315:             case PNG_COLOR_PALETTE:
> 316:                 return ImageStorage.ImageType.PALETTE;

Why was this case removed? Is it not used?

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

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2424642136
PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1834895733

From andy.goryachev at oracle.com  Fri Nov  8 21:25:53 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 8 Nov 2024 21:25:53 +0000
Subject: Prioritized event handlers
In-Reply-To: <d7282fbf-98d4-41ea-8f20-ae4eb8885332@gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
 <BL3PR10MB61851CB9CB5BD024A9534B55E55C2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <d7282fbf-98d4-41ea-8f20-ae4eb8885332@gmail.com>
Message-ID: <DS0PR10MB620008E7FB26876A24A401A8E55D2@DS0PR10MB6200.namprd10.prod.outlook.com>

Thanks, very interesting!

The first thing that popped up is that FX does expose the Skin's implementation via Node.lookup() and CSS.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Tobias Oelgarte <tobias.oelgarte at gmail.com>
Date: Friday, November 8, 2024 at 12:47
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers

This whole situation reminds me very much of Shadow DOM [1], an approach for components (controls/skins) with a complex internal structure that should not be visible from the outside. The handling of events could serve as a template here. [2]

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
[2] https://pm.dartus.fr/posts/2021/shadow-dom-and-event-propagation/
On 07.11.24 20:06, Andy Goryachev wrote:

> 4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

This is a very strange rationale, in my opinion.  And why talk about Controls when the Event.copyFor() is at the very fundamental level?  To me, this severely complicates everything, including breaking isConsumed() logic.  Sending events that are not designed to bubble up seems to run contrary to the whole event dispatching idea.  Are you trying to explain the current implementation?  Swing never needed to store the target in the event, and it works just fine.

This brings me to another problem I am struggling with: why expose the event dispatchers??  This should have never been done, in my opinion.  Swing's FwDispatcher is an implementation detail.  But instead, we seem to be dealing with unnecessarily increased complexity, including misbehaving EventDispatcher implementations.

May be it's just me, I don't see the beauty of this thing.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Thursday, November 7, 2024 at 05:35
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: Prioritized event handlers

Hi Andy,

Simply replacing a Skin can change the order of event handlers.  In other words, if you registered your handler **after** the control was shown, then replace its Skin (which can be done by CSS state changes), then your handler is now called before the Skin/Behavior handlers.  Also removing your own handlers, then installing them back (in the same order) will not lead to the same result either.  The culprit is simply that two different parties (FX and the User) are sharing the same system -- this is mostly fine for properties, but Events are stateful, and so the processing order matters.

I've given this quite a lot of thought recently, and I also looked at the Spinner problem, and I think I do have an all encompassing solution for both the ordering problem and the Spinner problem.

Observations:

Controls have some trouble keeping their Skin internals hidden from the outside world.  For the user, the Spinner is a black box; it is the thing that gets the focus and accepts input, even though the actual implementation may be delegating this to an internal component (in the case of the default SpinnerSkin, a FakeFocusTextField -- a detail that you can see "leaking" out when registering a listener on Scene#focusOwner).

Secondly, because Skins are re-using normal controls, which only work when focused, they sometimes have to "fake" the focus (this is a problem I won't be solving in this post).  IMHO however, this should be handled differently altogether, perhaps with some kind of focus delegation mechanism as part of Behaviors -- the user observable focus should IMHO always be the Control, as it is a black box.  The current fake focus implementation tries to keep this hidden (by not firing change listeners) which is incredibly dubious, and also fails (you can still see internals being focused with Scene#focusOwner).

Analysis:

Inside SpinnerSkin, there is a lot of jumping through hoops in the form of filtering events, copying them, and being aware of what the Behavior needs (SpinnerSkin for example knows that the Behavior has need of the UP/DOWN/LEFT/RIGHT keys, it shouldn't...) -- all this jumping through hoops is to make the internal TextField component receive events, but at the same time, not confusing the Behavior with duplicated events (as the Behavior handlers are in between the event root (the window) and the target (the internal textfield) events flow past the Behavior's handlers).

Solution:

The Behavior event handlers are at the Control level -- as far as the user is concerned, this is the target and also final destination (there is nothing deeper).  In effect you could say that the Behavior could register either a Filter or a Handler, and the result would be the same -- filtering down from Scene -> Node -> Spinner and then bubbling up from Spinner -> Node -> Scene, it shouldn't matter if the Behavior registers a filter or a handler as they're at the same position (of course there are some small differences, but I think we actually WANT filters in behaviors, more on this later).

One of the problems is that the event handlers in the behavior trigger **after** the internal TextField -- but we have the perfect mechanism to swap this around; if the Behavior registered a filter (which as I said earlier is sort of at the same position conceptually) then it would trigger **before** the internal TextField.  Spinner is then free to process and consume the arrow keys it needs, and the Skin would not need to be aware of this (ie. if a different Behavior decides to consume the +/- keys, then it would work with the current Skin).  The Skin then just forwards any events that arrive at the Control level still (everything minus potential arrow keys consumed by the Behavior) to the internal text field.

The second part of this solution relates to how to get Events to go down to the internal TextField.  Events are fired at the current focus owner, which is the Control.  The TextField only has fake focus.  So we need to take events that arrive at the Control, copy them and send them to the internal TextField.  However, there is a small problem -- the standard event mechanism will make such copies filter down from Window level all the way to the TextField level (passing the Spinner control).  But this isn't want we want at all.  Spinner is a black box; when we want to fire an event into the internals, we don't want this event to be exposed either (aside from the problems that causes, with having to be careful not to copy the event again as it will pass your forwarding handler again).  In effect, we want a different event dispatch hierarchy that is limited to the Control only.  So, why not build a dispatch chain that exclusively targets the internals?  This chain in this case only consists of one EventDispatcher, the one from the internal TextField.  The event copy is fired at it and the control works as expected.  It automatically also solves the "ENTER" problem described in https://bugs.openjdk.org/browse/JDK-8337246 without further hacks.

Takeaways:

I now think Behaviors should always be doing their event handling in filters, for the simple reason that they should get to act first before the Skin gets to act on an event; events arriving at the Control level which is the final destination can be handled by either a handler or a filter and there would be no discernible difference.  Not only does this solve the problem with the internal text field and the Skin needing to be aware of what keys Behavior will be handling, but it also then makes behaviors always act before user event handlers, creating consistency here (ie. replacing a Skin will not affect event handler order).  This frees up handlers for user purposes.  The ordering problem moves to the filters, so we may still want to do a solution here (see below).

Event handler order when Skins get re-added:

Handlers registered by users can change order with regards to handlers registered by Behaviors when the Skin change or depending on when the user registered their handlers.  This is problematic for events as they are stateful and can be consumed, and so an order change can lead to a functionality change. This is not user friendly, as the user expects that the event handler and filter infrastructure is for their use alone.  I can see a few things we could explore further:

- See if it is possible to add some internal API that allows Behaviors to register filters or handlers first/last -- note that "last" here means **always** last, even when user handlers are added later (first would be an easier option).
- See if it is possible to change how `buildEventDispatchChain` works for Controls to include another dispatcher level exclusively for Behaviors.   Where a standard chain would look like Window->Scene->Nodes->Control, it would become Window->Scene->Nodes->Control->Behavior(private) -- as this is a completely separate level, handlers from users and behaviors cannot become intertwined and so there will always be a predictable ordering

On 07/11/2024 01:03, Andy Goryachev wrote:
Dear Michael:

What happened to this proposal?  I would like to restart the discussion, if possible.

More specifically, I would like to discuss the following topics:


  1.  the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245<https://bugs.openjdk.org/browse/JDK-8231245> Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
  2.  dispatching of events that have been consumed (as mentioned in the earlier discussion)
  3.  problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246<https://bugs.openjdk.org/browse/JDK-8337246> SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
  4.  why do we need Event.copyFor() in the first place?  why does Event contain the target??

1. You would have the same problem with other events that Behaviors listen to (ie. mouse events), or events they handle without going through the input map (TYPED, RELEASED), or events they handle with a parent event type (all KeyEvents, not a specific one).

2. This is IMHO a bug, it only happens for the same event type at one level, it should simply be fixed

3. See above, but in short, I think the problem is not the event clones, but the fact that these clones are traversing the entire Window->Scene->Node hierarchy.  Events with a restricted hierarchy solve this.

4. The target allows you to register the same event handler instance multiple times on multiple different controls without having to create a new lambda each time that knows which control (target) it is for. It has a similar function to the Observable parameter in InvalidationListeners and ChangeListeners.  In effect, having the Target will also make it possible in the future to share a single input map with all controls of the same type (currently there is a ton of memory being wasted here duplicating input maps, especially for controls with large input maps like TextFields).

--John

Too many topics, yes, we might want to split the discussion into separate threads.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241108/513f4316/attachment-0001.htm>

From mstrauss at openjdk.org  Fri Nov  8 21:31:54 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 8 Nov 2024 21:31:54 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v18]
In-Reply-To: <TFAG7Gb2oeeoJGX83_rAvr1YjZkfT7vIU0hBcyYIkkA=.4920f482-a09c-4021-b289-ab8ae5c5eb2e@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <IZ0wHztUgrUTz0EL76PQURjh0RdnAadX6DOgEH82y-4=.f4f579c7-a2c6-4402-b646-17cba2b6b398@github.com>
 <TFAG7Gb2oeeoJGX83_rAvr1YjZkfT7vIU0hBcyYIkkA=.4920f482-a09c-4021-b289-ab8ae5c5eb2e@github.com>
Message-ID: <O-L7jcqtFq8HTXN-JG1vh9rjQHe2ZioAMeYukfwdraI=.70923d98-5b95-449b-a93b-7f4ecf46f758@github.com>

On Fri, 8 Nov 2024 18:44:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - move automatically added imports
>>  - rename test...javax -> test...java2d
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoader2.java line 316:
> 
>> 314:                         : ImageStorage.ImageType.RGB;
>> 315:             case PNG_COLOR_PALETTE:
>> 316:                 return ImageStorage.ImageType.PALETTE;
> 
> Why was this case removed? Is it not used?

`PNG_COLOR_PALETTE` is always decoded into an RGB/A `ImageType`, never into a palette type. See L684:

        ImageFrame imgPNG = colorType == PNG_COLOR_PALETTE
                ? decodePalette(bb.array(), metaData)
                : new ImageFrame(getType(), bb, width, height, bpp * width, metaData);


The `getType()` method is never invoked with `PNG_COLOR_PALETTE`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1835076460

From jhendrikx at openjdk.org  Fri Nov  8 21:48:44 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 8 Nov 2024 21:48:44 GMT
Subject: RFR: 8091673: Public focus traversal API for use in custom
 controls [v5]
In-Reply-To: <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
 <TpvzUTFDoDfP4QAmYUUMzK3rpNBFj7bTduSwPqNnghs=.11d95a9c-bd7b-4bdc-9304-612f2817e3b5@github.com>
Message-ID: <wEjlZDGmFHMw5rC8oEa11lUD2sql6uO182a3S0zfBNU=.28b45151-bed5-44e1-8068-6180eab67ab4@github.com>

On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Public focus traversal API for use in custom controls.
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>> 
>> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   focus visible

Looks good, a lot easier to review this way, thanks!

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1628#pullrequestreview-2424972891

From kcr at openjdk.org  Fri Nov  8 21:54:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 8 Nov 2024 21:54:22 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager
Message-ID: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>

Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.

As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.

In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).

Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

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

Commit messages:
 - 8342994: Remove security manager calls in com.sun.javafx.reflect
 - 8342997: Remove use of System::getSecurityManager and SecurityManager

Changes: https://git.openjdk.org/jfx/pull/1631/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1631&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342997
  Stats: 870 lines in 33 files changed: 10 ins; 829 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1631.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1631/head:pull/1631

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

From mfox at openjdk.org  Fri Nov  8 22:08:44 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 8 Nov 2024 22:08:44 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
 <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
 <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>
Message-ID: <UGYJU6GsKKyZx4tIxxMlgpjtf64oXccrakOYhEg4TVA=.874be2ef-2086-4125-9ecf-5ff6e1a13792@github.com>

On Fri, 8 Nov 2024 20:44:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> @kleopatra Your explanation makes sense to me. Thank you for taking the time to write it up.
>> 
>> If so, the proposed fix, including adjusting the comment, would be:
>> 
>> 
>> --- a/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
>> +++ b/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
>> @@ -162,9 +162,8 @@ public class TextFieldBehavior extends TextInputControlBehavior<TextField> {
>> 
>>          textField.commitValue();
>>          textField.fireEvent(actionEvent);
>> -        // fix of JDK-8207759: reverted logic
>> -        // mapping not auto-consume and consume if handled by action
>> -        if (onAction != null || actionEvent.isConsumed()) {
>> +        // Consume the original event if the copied actionEvent was consumed.
>> +        if (actionEvent.isConsumed()) {
>>              event.consume();
>>          }
>>      }
>
> You are right, `&&` would be insufficient as there is another way to add action handlers.  I didn't really see that, although the fix I had in mind was to eliminate the `onAction` variable completely (it is unused in your fix as well), so probably would have ended up at the correct result :)
> 
> I can roll this into a small PR if you wish.

FWIW, checking the isConsumed flag will only work if the action is consumed by a handler registered directly with the TextField. If there's a filter or handler attached to some other part of the scene graph a copy of the event will be made and consumed and `actionEvent.isConsumed()` will return false. A more complete fix is to replace `textField.fireEvent` with a call to `EventUtil.fireEvent` and check for a `null` return value.

If I understand this thread correctly if a KeyEvent generates an ActionEvent the KeyEvent should only be consumed if the ActionEvent is. If so the behavior should be consistent across TextFields and the controls that manage TextFields internally (Spinner, ComboBox, and DatePicker). I'm already working on a test for Escape key handling for this set of controls (for Escape the issue is whether a formatter is attached or not). I'm willing to write up a similar test for Enter handling for the same set of controls. I just need to make sure I understand exactly what behavior is expected.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1835102922

From angorya at openjdk.org  Fri Nov  8 22:27:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 8 Nov 2024 22:27:57 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <a0s8HxmODxpxMYvDxPAwzHv2a6wHJzlwhqjJiy2QAG4=.4349c475-67f1-4d40-af2a-e33d54ef7f23@github.com>

On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

changes look good.

the only suggestion I have is to create the cleanup ticket, explain what needs to be done, link this PR and use that JBS number in the comments instead of "SM removal".

modules/javafx.base/src/main/java/com/sun/javafx/reflect/ReflectUtil.java line 82:

> 80:      */
> 81:     public static void checkPackageAccess(String name) {
> 82:         @SuppressWarnings("removal")

will there be a ticket for further cleanup of unused/unnecessary methods?

modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontFactory.java line 55:

> 53:     public String[] getFontFullNames(String family);
> 54: 
> 55:     // TODO: SM removal: condider removing in a follow-up issue

maybe it's better to create a ticket and reference that instead?

modules/javafx.graphics/src/main/java/javafx/scene/input/Dragboard.java line 52:

> 50:     @Override
> 51:     Object getContentImpl(DataFormat dataFormat) {
> 52:         if (dataAccessRestricted) {

this method can be deleted here

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1631#pullrequestreview-2424996037
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1835103488
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1835106214
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1835109620

From jhendrikx at openjdk.org  Sat Nov  9 00:24:54 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 9 Nov 2024 00:24:54 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <UGYJU6GsKKyZx4tIxxMlgpjtf64oXccrakOYhEg4TVA=.874be2ef-2086-4125-9ecf-5ff6e1a13792@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
 <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
 <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>
 <UGYJU6GsKKyZx4tIxxMlgpjtf64oXccrakOYhEg4TVA=.874be2ef-2086-4125-9ecf-5ff6e1a13792@github.com>
Message-ID: <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com>

On Fri, 8 Nov 2024 22:05:15 GMT, Martin Fox <mfox at openjdk.org> wrote:

> FWIW, checking the isConsumed flag will only work if the action is consumed by a handler registered directly with the TextField. If there's a filter or handler attached to some other part of the scene graph a copy of the event will be made and consumed and `actionEvent.isConsumed()` will return false. A more complete fix is to replace `textField.fireEvent` with a call to `EventUtil.fireEvent` and check for a `null` return value.

It seems that an earlier check I did to see if events are copied wasn't done correctly.  Indeed events are copied at every filter/handler.  That does seem excessive.  It also makes the public `Node#fireEvent` a bit useless for proper event propagation for normal users that don't have access to `EventUtil`.

I checked the events that are copied, and it is basically making the copy to adjust the source (target remains constant).  That's really odd; I'd expect the source to remain the same as well (ie. the Scene or Window, not the "previous" filter/handler Node level), especially as it is documented as:

    /**
     * The object on which the Event initially occurred.
     *
     * @return the object on which the Event initially occurred
     */
    public Object getSource() {
        return source;
    }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1835173141

From mfox at openjdk.org  Sat Nov  9 00:52:40 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 9 Nov 2024 00:52:40 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
 <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
 <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>
 <UGYJU6GsKKyZx4tIxxMlgpjtf64oXccrakOYhEg4TVA=.874be2ef-2086-4125-9ecf-5ff6e1a13792@github.com>
 <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com>
Message-ID: <GyLhwl3Wxv-jcSM9uH5FGwyJOMrJt6lFZJxH0aFOnT4=.556987b8-f688-47f9-a1e3-47606ab751c9@github.com>

On Sat, 9 Nov 2024 00:22:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I checked the events that are copied, and it is basically making the copy to adjust the source (target remains constant). That's really odd; I'd expect the source to remain the same as well (ie. the Scene or Window, not the "previous" filter/handler Node level), especially as it is documented as:

I haven't walked through this in AWT (there are only so many hours in the day) but I believe the AWT `source` corresponds to the JavaFX `target` i.e. the object the event was fired against. JavaFX repurposes `source` as the object the handler or filter was registered on. JavaFX shouldn't be pointing at the AWT documentation since it doesn't match the JavaFX implementation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1835181134

From michaelstrau2 at gmail.com  Sat Nov  9 01:33:02 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 9 Nov 2024 02:33:02 +0100
Subject: Focus delegation API
Message-ID: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>

Hi everyone,

here is a proposal to finally solve the focus delegation problem that
has recently been discussed in the "Prioritized event handlers"
thread.

Proposal: https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29
Draft PR: https://github.com/openjdk/jfx/pull/1632

From michaelstrau2 at gmail.com  Sat Nov  9 01:35:52 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 9 Nov 2024 02:35:52 +0100
Subject: Prioritized event handlers
In-Reply-To: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com>
Message-ID: <CAJEpuXS626HxigsxYsfmJY52O2Tvap81_gcnLjeMSYRANYhVmQ@mail.gmail.com>

I agree with this analysis, and I've taken the liberty to steal parts
of your code for this PR:
https://github.com/openjdk/jfx/pull/1632

On Thu, Nov 7, 2024 at 3:06?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
> [...]
> I now think Behaviors should always be doing their event handling in filters, for the simple reason that they should get to act first before the Skin gets to act on an event; events arriving at the Control level which is the final destination can be handled by either a handler or a filter and there would be no discernible difference.  Not only does this solve the problem with the internal text field and the Skin needing to be aware of what keys Behavior will be handling, but it also then makes behaviors always act before user event handlers, creating consistency here (ie. replacing a Skin will not affect event handler order).  This frees up handlers for user purposes.
> [...]

From michaelstrau2 at gmail.com  Sat Nov  9 01:52:04 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 9 Nov 2024 02:52:04 +0100
Subject: Prioritized event handlers
In-Reply-To: <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>

Hi Andy,

1. What happened to this proposal?

I've come to the conclusion that we need something like that, but
probably in a different form. My current thinking is that we don't
need prioritized handlers, but merely a way for interested listeners
to say "I'll take this event, but only if no one else wants it".
A possible API could be something like the following:

target.addEventHandler(KeyEvent.PRESSED, event -> {
    event.ifUnconsumed(evt -> {
        // This will be called after the event has bubbled up
        // without being consumed.
    });
});

This will allow skins to act on events only if user code didn't consume them.

2. Does it make sense to change the API at the EventDispatcher level
when the problem can be easily solved by the InputMap at the Control
level?

Yes, because javafx.controls is not a core part of JavaFX, and it
should never be. People should be free to create their own controls
implementation, or alternative skinning systems. We need to give them
the tools to do so, and not continue the anti-pattern of shifting core
functionality into javafx.controls and special-casing this module even
more than it is already special-cased.

3. dispatching of events that have been consumed (as mentioned in the
earlier discussion)

Probably not necessary. Once an event is consumed, it's gone; we don't
need to dispatch it further.

4. Problem of creating unnecessary clones of events via Event.copyFor()

Unless there is a clear performance problem, I consider any
fundamental change here as a solution in search of a problem.
Events are usually not so plentiful that we're talking about serious
CPU cycles here. The highest-frequency events are probably mouse
events, and they happen at most hundreds of times per second.

5. If we removed the target, then a listener couldn't discern whether
the event was targeted at the receiving node, or at a descendant of
the node.



On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev <andy.goryachev at oracle.com> wrote:
>
> Dear Michael:
> What happened to this proposal?  I would like to restart the discussion, if possible.
>
> More specifically, I would like to discuss the following topics:
>
> the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
> dispatching of events that have been consumed (as mentioned in the earlier discussion)
> problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
> why do we need Event.copyFor() in the first place?  why does Event contain the target??
>

From mstrauss at openjdk.org  Sat Nov  9 07:45:19 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 9 Nov 2024 07:45:19 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v27]
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: <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>

> Implementation of [`EXTENDED` stage style](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 34 commits:

 - Merge branch 'master' into feature/extended-window
 - Merge branch 'master' into feature/extended-window
 - add system menu documentation
 - WindowControlsOverlay snapping
 - HeaderBar javadoc change
 - refactor performWindowDrag
 - HeaderBar changes
 - EMPTY Dimension2D constant
 - use CsvSource in HeaderBarTest
 - stylistic changes
 - ... and 24 more: https://git.openjdk.org/jfx/compare/d0011b21...65f095ef

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=26
  Stats: 4882 lines in 61 files changed: 4368 ins; 409 del; 105 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  Sat Nov  9 07:45:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 9 Nov 2024 07:45:14 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v8]
In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
Message-ID: <a1RYq163Pfw6_TB9BufjB0P7V263A2L0QOYbgsvkoh0=.2d367dcb-1e0e-4be4-acd0-fda0820d03c7@github.com>

> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
> 
> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)).
> 
> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change.

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

 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - Merge branch 'master' into feature/sealed-classes
 - add comment
 - Merge branch 'master' into feature/sealed-classes
 - remove documentation
 - Seal Node, Camera, LightBase, Shape, Shape3D

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

Changes: https://git.openjdk.org/jfx/pull/1556/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=07
  Stats: 215 lines in 46 files changed: 93 ins; 41 del; 81 mod
  Patch: https://git.openjdk.org/jfx/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556

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

From mstrauss at openjdk.org  Sat Nov  9 07:43:43 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 9 Nov 2024 07:43:43 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v19]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

 - Merge branch 'master' into feature/ximageloader
 - move automatically added imports
 - rename test...javax -> test...java2d
 - Merge branch 'master' into feature/ximageloader
 - Merge branch 'master' into feature/ximageloader
 - rename iio.javax -> iio.java2d
 - revert doc change
 - Merge branch 'master' into feature/ximageloader
 - validate max image width/height
 - catch NoClassDefFoundError
   
   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
 - ... and 23 more: https://git.openjdk.org/jfx/compare/d0011b21...d8d2a9c1

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

Changes: https://git.openjdk.org/jfx/pull/1593/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=18
  Stats: 3830 lines in 36 files changed: 3031 ins; 632 del; 167 mod
  Patch: https://git.openjdk.org/jfx/pull/1593.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1593/head:pull/1593

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

From jhendrikx at openjdk.org  Sat Nov  9 11:01:16 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 9 Nov 2024 11:01:16 GMT
Subject: RFR: 8207759: VK_ENTER not consumed by TextField when default
 Button exists [v3]
In-Reply-To: <GyLhwl3Wxv-jcSM9uH5FGwyJOMrJt6lFZJxH0aFOnT4=.556987b8-f688-47f9-a1e3-47606ab751c9@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <IXneqhGIxfeeVTHFd_HvtYMv208KLOC1z3mBEK0IqcY=.df2de3ff-e826-410a-b53a-319ab7b2efae@github.com>
 <kAKrBIJH-GRQl0j4VFe6R50E-2TcR7Xozp6HphRN5lY=.b677b29c-8bcf-4658-8fca-c70d117e81ad@github.com>
 <aJlVdnOvRhsCfYkjtigWWIcsNuErLAvKL0pidXkKhpM=.f234b5dd-18ab-4a75-ab01-8c0fcc6364bc@github.com>
 <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com>
 <F-TW8jBFzCNRkQNdubIvZa3FibEQnOujiWqut-hS0CQ=.73da0057-7bf4-414d-85ee-6f05a627ea23@github.com>
 <UGYJU6GsKKyZx4tIxxMlgpjtf64oXccrakOYhEg4TVA=.874be2ef-2086-4125-9ecf-5ff6e1a13792@github.com>
 <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com>
 <GyLhwl3Wxv-jcSM9uH5FGwyJOMrJt6lFZJxH0aFOnT4=.556987b8-f688-47f9-a1e3-47606ab751c9@github.com>
Message-ID: <JEB5D1gvWn5cc9-T5Q-omwMqOmLGvbpyntT2q2iVDEM=.17474b41-b59c-4230-90de-c88e7bc52ea7@github.com>

On Sat, 9 Nov 2024 00:49:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > I checked the events that are copied, and it is basically making the copy to adjust the source (target remains constant). That's really odd; I'd expect the source to remain the same as well (ie. the Scene or Window, not the "previous" filter/handler Node level), especially as it is documented as:
> 
> I haven't walked through this in AWT (there are only so many hours in the day) but I believe the AWT `source` corresponds to the JavaFX `target` i.e. the object the event was fired against. JavaFX repurposes `source` as the object the handler or filter was registered on. JavaFX shouldn't be pointing at the AWT documentation since it doesn't match the JavaFX implementation.

Well, it implements AWT's `EventObject` through `class Event extends EventObject` -- it would be rather silly to repurpose `getSource` for something else, but then still extend AWT's `EventObject`. 

The class docs of `Event` mention an event source, and describes it as "The event source specifies for an event handler the object on which that handler has been registered and which sent  the event to it" -- that sentence is rather hard to decode, but I guess their meaning is that the Event received by your event handler will have its source set to the object where you registered your handler (ie. a `Node` in most cases) -- it would be similar to `getBean` for properties, but in an far more roundabout way.

And then there's a constructor for `Event` that mentions source being `the event source which sent the event`.

So basically, there are now three definitions of source, two that seem constant, and one that requires an event to be copied before having an event filter or handler receive it...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/15#discussion_r1835339027

From michaelstrau2 at gmail.com  Sun Nov 10 07:12:57 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sun, 10 Nov 2024 08:12:57 +0100
Subject: Unconsumed event handlers
Message-ID: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>

In JavaFX, user code and skins share the same event system. Since
invocation order is fundamentally important for events, this leads to
a lot of problems when skins add event handlers to their controls.
Assume user code adds an event handler to a control, and _then_ sets a
skin that also adds an event handler for the same event. In this case,
the user-provided handler is invoked first. If the skin is set
_first_, the skin gets the first chance to handle the event (see also
https://bugs.openjdk.org/browse/JDK-8231245).

Prioritized event handlers might be a solution for this problem, but
they are quite difficult to get right. Instead, I think we can get
almost all of the benefits using a much simpler solution: unconsumed
event handlers.

We add a new method to the `Event` class:

    <E extends Event> void ifUnconsumed(EventHandler<E> handler)

When an event filter or an event handler receives an event, it calls
the `ifUnconsumed` method with another event handler. Then, after both
phases of event delivery have completed, the list of unconsumed event
handlers associated with the event is invoked in sequence. Once an
unconsumed event handler consumes the event, further propagation is
stopped.

Skins and their behaviors would then always use the unconsumed form of
event handlers:

    // inside a skin/behavior
    control.addEventHandler(
        KeyEvent.KEY_PRESSED,
        e -> e.ifUnconsumed(event -> {
            // act on the event
        }));

This allows user code to see an event during both the capture and
bubble phases without any inteference of the skin or behavior. If user
code doesn't consume the event, the skin or behavior gets to act on
it.

In addition to that, we add a second new method to the `Event` class:

    void discardUnconsumedEventHandlers()

Calling this method in an event handler allows user code to discard
any unconsumed event handlers that have been registered prior. Let's
consider an example where user code wants to prevent a control skin
from acting on the ENTER key event, but it also doesn't want to
consume the event. Adding an event handler to the control, and then
calling `discardUnconsumedEventHandlers()` inside of the event handler
achieves exactly that: it allows the ENTER key event to flow freely
through the control without interacting with it, since its unconsumed
event handlers will never be called.

Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633

From lkostyra at openjdk.org  Mon Nov 11 08:26:02 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 11 Nov 2024 08:26:02 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <gLWXnxErOSslkS-ha5AY-SSMBwWMQgbCBASrKXOVF1Q=.4ba2d4a2-7651-4732-97f3-f9b9d4bb48b4@github.com>

On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Looks good, noticed one detail to iron out

modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 107:

> 105: 
> 106:     // Indicates permission to get the ClassLoader
> 107:     private static final RuntimePermission GET_CLASSLOADER_PERMISSION =

I think this is unused and can be removed too

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

PR Review: https://git.openjdk.org/jfx/pull/1631#pullrequestreview-2426361005
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1836108609

From john.hendrikx at gmail.com  Mon Nov 11 09:05:06 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 11 Nov 2024 10:05:06 +0100
Subject: Focus delegation API
In-Reply-To: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
Message-ID: <cb6ae744-c20d-4a4a-b093-da39eade539f@gmail.com>

Really liking this approach.? Thank you for working on this!

I didn't have a comprehensive solution for handling external and 
internal focus yet, and only tried solving the event delegation 
problem.? This solution not only solves that, but also in such a way 
that 3rd parties can use the same solution in their custom controls.? It 
would be a solid addition to FX as closes the gap a bit between FX 
controls and custom controls.

There is one thing we may also want to consider (although probably not 
as part of this solution).? I was thinking that we still are mixing up 
filters/handlers of behaviors with user filters/handlers.? The order of 
these can change depending on what is installed first, or when Skins are 
exchanged.? But if Control had a custom event dispatcher, it could 
pretty easily place the filters/handlers of Behaviors somewhere else.? 
For events handled that would mean there's an additional level in the 
event dispatch chain, instead of:

 ??? Window -> Scene -> Node -> Control -> Internals

It would become

 ??? Window -> Scene -> Node -> Control -> Behavior filter/handlers -> 
Internals

As Behaviors would have their own separate filter/handler lists, there 
can never be interference with user handlers, and the order in which 
events are handled will always be the same.? It could also make 
installing/uninstalling behaviors easier, as you can just throw away all 
filter/handlers installed on the special Behavior filter/handler lists 
when a behavior is replaced.

--John

On 09/11/2024 02:33, Michael Strau? wrote:
> Hi everyone,
>
> here is a proposal to finally solve the focus delegation problem that
> has recently been discussed in the "Prioritized event handlers"
> thread.
>
> Proposal: https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29
> Draft PR: https://github.com/openjdk/jfx/pull/1632

From john.hendrikx at gmail.com  Mon Nov 11 09:21:16 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 11 Nov 2024 10:21:16 +0100
Subject: Prioritized event handlers
In-Reply-To: <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
Message-ID: <4bf95dcf-3b29-4411-b3d4-4f7caf919314@gmail.com>

Some comments in line.

On 09/11/2024 02:52, Michael Strau? wrote:
> Hi Andy,
>
> 1. What happened to this proposal?
>
> I've come to the conclusion that we need something like that, but
> probably in a different form. My current thinking is that we don't
> need prioritized handlers, but merely a way for interested listeners
> to say "I'll take this event, but only if no one else wants it".
> A possible API could be something like the following:
>
> target.addEventHandler(KeyEvent.PRESSED, event -> {
>      event.ifUnconsumed(evt -> {
>          // This will be called after the event has bubbled up
>          // without being consumed.
>      });
> });
>
> This will allow skins to act on events only if user code didn't consume them.

Yeah, this similar to what Scene does, it waits for events to bubble 
back up, then handles navigation or default buttons. Having a mechanism 
to hook into this may be a good idea.

We may not need this if there is a way to easily change and replace 
Behaviors separate from Skins, as the users would then have the option 
to replace or alter a Behavior if the standard one interferes with a 
specific event they're interested in.? Currently there is little 
recourse when this happens, as you'd have to replace the entire Skin to 
do such a change.

> 2. Does it make sense to change the API at the EventDispatcher level
> when the problem can be easily solved by the InputMap at the Control
> level?
>
> Yes, because javafx.controls is not a core part of JavaFX, and it
> should never be. People should be free to create their own controls
> implementation, or alternative skinning systems. We need to give them
> the tools to do so, and not continue the anti-pattern of shifting core
> functionality into javafx.controls and special-casing this module even
> more than it is already special-cased.
>
> 3. dispatching of events that have been consumed (as mentioned in the
> earlier discussion)
>
> Probably not necessary. Once an event is consumed, it's gone; we don't
> need to dispatch it further.
>
> 4. Problem of creating unnecessary clones of events via Event.copyFor()
>
> Unless there is a clear performance problem, I consider any
> fundamental change here as a solution in search of a problem.
> Events are usually not so plentiful that we're talking about serious
> CPU cycles here. The highest-frequency events are probably mouse
> events, and they happen at most hundreds of times per second.
>
> 5. If we removed the target, then a listener couldn't discern whether
> the event was targeted at the receiving node, or at a descendant of
> the node.

The target is also not the biggest problem.? The source changes much 
more often (as can be seen also in your focus delegation document).? I 
however agree with the assessment that these few copies are simply not a 
problem at all.

--John

>
>
>
> On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev <andy.goryachev at oracle.com> wrote:
>> Dear Michael:
>> What happened to this proposal?  I would like to restart the discussion, if possible.
>>
>> More specifically, I would like to discuss the following topics:
>>
>> the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
>> dispatching of events that have been consumed (as mentioned in the earlier discussion)
>> problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
>> why do we need Event.copyFor() in the first place?  why does Event contain the target??
>>

From ambarish.rapte at oracle.com  Mon Nov 11 10:10:06 2024
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 11 Nov 2024 10:10:06 +0000
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <PH7PR10MB7850E1306AA15AF143CE6A52F0582@PH7PR10MB7850.namprd10.prod.outlook.com>

Vote: YES

~ Ambarish

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Friday, 8 November 2024 at 7:17?PM
To: openjfx-dev <openjfx-dev at openjdk.org>, Jayathirth Rao Daarapuram Venkatesh Murthy <jayathirth.d.v at oracle.com>
Subject: CFV: New OpenJFX Committer: Jayathirth D V
I hereby nominate Jayathirth D V [1] to OpenJFX Committer.

Jay is a member of the JavaFX team at Oracle who has contributed 12
commits [2] to OpenJFX. He has contributed an additional 5 commits to
the OpenJFX jfx-tests repo [3].

Votes are due by November 22, 2024 at 14:00 UTC.

Only current OpenJFX Committers [4] 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 [5]. Nomination to a project
Committer is described in [6].

Thanks.

-- Kevin


[1] https://openjdk.org/census#jdv

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Jayathirth%22&type=commits

[3]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx-tests+author-name%3A%22Jayathirth%22&type=commits

[4] https://openjdk.org/census#openjfx

[5] https://openjdk.org/bylaws#lazy-consensus

[6] https://openjdk.org/projects#project-committer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241111/c178db89/attachment-0001.htm>

From mfox at openjdk.org  Mon Nov 11 18:01:18 2024
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 11 Nov 2024 18:01:18 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod
Message-ID: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>

Input methods don?t work for text controls inside Popups. This PR fixes that.

Some background:

A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows.

Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom.

The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene.

There are several reasons why Input Methods aren?t currently working for Popups.

- InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents.

- If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events.

- The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents.

In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack.

This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the change. In this PR the InputMethodStateManager installs listeners on the focusOwner to detect changes in the IM configuration.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into imeenable
 - finishInputMethodComposition is only called when focus changes on the event scene
 - Updated comments
 - Merge remote-tracking branch 'upstream/master' into imeenable
 - Added InputMethodStateManager to coordinate input method usage betwee Popups and their root Scene.

Changes: https://git.openjdk.org/jfx/pull/1634/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1634&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288893
  Stats: 279 lines in 4 files changed: 264 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1634.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1634/head:pull/1634

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

From mfox at openjdk.org  Mon Nov 11 19:34:04 2024
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 11 Nov 2024 19:34:04 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod [v2]
In-Reply-To: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
References: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
Message-ID: <dA_ualGgW30zAI0ruIfLmHxAz22-QYSMsl1hjH6_eSQ=.a77f7453-935b-4daa-a916-8bfc7d7697a3@github.com>

> Input methods don?t work for text controls inside Popups. This PR fixes that.
> 
> Some background:
> 
> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows.
> 
> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom.
> 
> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene.
> 
> There are several reasons why Input Methods aren?t currently working for Popups.
> 
> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents.
> 
> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events.
> 
> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents.
> 
> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack.
> 
> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the change. In this PR the InputMethodStateManage...

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

  Fixed javadoc failure

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1634/files
  - new: https://git.openjdk.org/jfx/pull/1634/files/cbae2c9b..43a4e6c4

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

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

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

From michaelstrau2 at gmail.com  Mon Nov 11 21:09:42 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 11 Nov 2024 22:09:42 +0100
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <CAJEpuXStM-noaw-zcJqkWXdT_n8c7HX+QNE=aSfA4X-rEuVq8Q@mail.gmail.com>

Vote: YES

On Fri, Nov 8, 2024 at 2:47?PM Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> I hereby nominate Jayathirth D V [1] to OpenJFX Committer.
>
> Jay is a member of the JavaFX team at Oracle who has contributed 12
> commits [2] to OpenJFX. He has contributed an additional 5 commits to
> the OpenJFX jfx-tests repo [3].
>
> Votes are due by November 22, 2024 at 14:00 UTC.
>
> Only current OpenJFX Committers [4] 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 [5]. Nomination to a project
> Committer is described in [6].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#jdv
>
> [2]
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Jayathirth%22&type=commits
>
> [3]
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx-tests+author-name%3A%22Jayathirth%22&type=commits
>
> [4] https://openjdk.org/census#openjfx
>
> [5] https://openjdk.org/bylaws#lazy-consensus
>
> [6] https://openjdk.org/projects#project-committer
>

From ajit.ghaisas at oracle.com  Tue Nov 12 04:44:39 2024
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Tue, 12 Nov 2024 04:44:39 +0000
Subject: CFV: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <6344DBFB-0B90-4C2D-8112-85EA343B6FE5@oracle.com>

Vote: YES

Regards,
Ajit

> On 8 Nov 2024, at 7:16?PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I hereby nominate Jayathirth D V [1] to OpenJFX Committer.
> 
> Jay is a member of the JavaFX team at Oracle who has contributed 12 commits [2] to OpenJFX. He has contributed an additional 5 commits to the OpenJFX jfx-tests repo [3].
> 
> Votes are due by November 22, 2024 at 14:00 UTC.
> 
> Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.org/census#jdv
> 
> [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Jayathirth%22&type=commits
> 
> [3] https://github.com/search?q=repo%3Aopenjdk%2Fjfx-tests+author-name%3A%22Jayathirth%22&type=commits
> 
> [4] https://openjdk.org/census#openjfx
> 
> [5] https://openjdk.org/bylaws#lazy-consensus
> 
> [6] https://openjdk.org/projects#project-committer
> 


From john.hendrikx at gmail.com  Tue Nov 12 13:02:25 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 12 Nov 2024 14:02:25 +0100
Subject: Unconsumed event handlers
In-Reply-To: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
Message-ID: <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com>

I think?`discardUnconsumedEventHandlers` is still a bit unpredictable, 
as it would depend on handler order.

The user handler would need to be called *after* Skin/Behavior handlers 
for it to be able to always discard any ifUnconsumed callbacks.? If the 
Skin is replaced, then it will re-register handlers and those will then 
be called last...

Of course, if we change Behaviors to do their work in filters, then we 
could get this to work properly.

--John

On 10/11/2024 08:12, Michael Strau? wrote:
> In JavaFX, user code and skins share the same event system. Since
> invocation order is fundamentally important for events, this leads to
> a lot of problems when skins add event handlers to their controls.
> Assume user code adds an event handler to a control, and _then_ sets a
> skin that also adds an event handler for the same event. In this case,
> the user-provided handler is invoked first. If the skin is set
> _first_, the skin gets the first chance to handle the event (see also
> https://bugs.openjdk.org/browse/JDK-8231245).
>
> Prioritized event handlers might be a solution for this problem, but
> they are quite difficult to get right. Instead, I think we can get
> almost all of the benefits using a much simpler solution: unconsumed
> event handlers.
>
> We add a new method to the `Event` class:
>
>      <E extends Event> void ifUnconsumed(EventHandler<E> handler)
>
> When an event filter or an event handler receives an event, it calls
> the `ifUnconsumed` method with another event handler. Then, after both
> phases of event delivery have completed, the list of unconsumed event
> handlers associated with the event is invoked in sequence. Once an
> unconsumed event handler consumes the event, further propagation is
> stopped.
>
> Skins and their behaviors would then always use the unconsumed form of
> event handlers:
>
>      // inside a skin/behavior
>      control.addEventHandler(
>          KeyEvent.KEY_PRESSED,
>          e -> e.ifUnconsumed(event -> {
>              // act on the event
>          }));
>
> This allows user code to see an event during both the capture and
> bubble phases without any inteference of the skin or behavior. If user
> code doesn't consume the event, the skin or behavior gets to act on
> it.
>
> In addition to that, we add a second new method to the `Event` class:
>
>      void discardUnconsumedEventHandlers()
>
> Calling this method in an event handler allows user code to discard
> any unconsumed event handlers that have been registered prior. Let's
> consider an example where user code wants to prevent a control skin
> from acting on the ENTER key event, but it also doesn't want to
> consume the event. Adding an event handler to the control, and then
> calling `discardUnconsumedEventHandlers()` inside of the event handler
> achieves exactly that: it allows the ENTER key event to flow freely
> through the control without interacting with it, since its unconsumed
> event handlers will never be called.
>
> Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633

From pavelturk2000 at gmail.com  Tue Nov 12 15:07:41 2024
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 12 Nov 2024 17:07:41 +0200
Subject: My bug report seems to have been lost
Message-ID: <2d508929-023e-457a-af22-4e3d3773eb50@gmail.com>

Hello?everyone,

I?submitted?a?bug?report?on?November?6,?but?I?still?haven?t?received?any?notification?about?it.

Review?ID?-?9077800.?The?bug?was?about?Font.loadFont()

Best?regards,?Pavel

From mfox at openjdk.org  Tue Nov 12 15:08:11 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 12 Nov 2024 15:08:11 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod [v3]
In-Reply-To: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
References: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
Message-ID: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com>

> Input methods don?t work for text controls inside Popups. This PR fixes that.
> 
> Some background:
> 
> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows.
> 
> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom.
> 
> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene.
> 
> There are several reasons why Input Methods aren?t currently working for Popups.
> 
> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents.
> 
> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events.
> 
> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents.
> 
> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack.
> 
> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the change. In this PR the InputMethodStateManage...

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

  Tweak to satisfy system test.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1634/files
  - new: https://git.openjdk.org/jfx/pull/1634/files/43a4e6c4..ce980548

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

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

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

From mfox at openjdk.org  Tue Nov 12 15:08:17 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 12 Nov 2024 15:08:17 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod [v2]
In-Reply-To: <dA_ualGgW30zAI0ruIfLmHxAz22-QYSMsl1hjH6_eSQ=.a77f7453-935b-4daa-a916-8bfc7d7697a3@github.com>
References: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
 <dA_ualGgW30zAI0ruIfLmHxAz22-QYSMsl1hjH6_eSQ=.a77f7453-935b-4daa-a916-8bfc7d7697a3@github.com>
Message-ID: <jZFfuDdSGoCl54JqxZcB4PQanUxvH2S3eLGxcs5eqvg=.c3872ae3-2228-4bf3-9da4-0a01f9d6ed66@github.com>

On Mon, 11 Nov 2024 19:34:04 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Input methods don?t work for text controls inside Popups. This PR fixes that.
>> 
>> Some background:
>> 
>> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows.
>> 
>> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom.
>> 
>> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene.
>> 
>> There are several reasons why Input Methods aren?t currently working for Popups.
>> 
>> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents.
>> 
>> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events.
>> 
>> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents.
>> 
>> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack.
>> 
>> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha...
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed javadoc failure

Converting to Draft. My testing macros weren't setup correctly and I missed a test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2469005330

From kevin.rushforth at oracle.com  Tue Nov 12 15:58:07 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 12 Nov 2024 07:58:07 -0800
Subject: My bug report seems to have been lost
In-Reply-To: <2d508929-023e-457a-af22-4e3d3773eb50@gmail.com>
References: <2d508929-023e-457a-af22-4e3d3773eb50@gmail.com>
Message-ID: <399b2bdd-540f-4197-856d-5e07695df1a9@oracle.com>

This is now visible here:

https://bugs.openjdk.org/browse/JDK-8344037

-- Kevin


On 11/12/2024 7:07 AM, PavelTurk wrote:
> Hello?everyone,
>
> I?submitted?a?bug?report?on?November?6,?but?I?still?haven?t?received?any?notification?about?it. 
>
>
> Review?ID?-?9077800.?The?bug?was?about?Font.loadFont()
>
> Best?regards,?Pavel


From kevin.rushforth at oracle.com  Tue Nov 12 16:22:53 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 12 Nov 2024 08:22:53 -0800
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
Message-ID: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>

I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.

Lukasz is a member of JavaFX team at Oracle, who has contributed 35 
commits [2] to OpenJFX. Lukasz consistently participates in code reviews 
of various pull requests, especially in the graphics area.

Votes are due by Nov 26, 2024 at 17:00 UTC.

Only current OpenJFX Reviewers [3] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4]. Nomination to a 
project Reviewer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#lkostyra

[2] 
https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#three-vote-consensus

[5] https://openjdk.java.net/projects#project-reviewer


From kevin.rushforth at oracle.com  Tue Nov 12 16:23:34 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 12 Nov 2024 08:23:34 -0800
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <44b35a7a-f3e3-4aff-8404-57966c8046bc@oracle.com>

Vote: YES

-- Kevin

On 11/12/2024 8:22 AM, Kevin Rushforth wrote:
> I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.

From andy.goryachev at oracle.com  Tue Nov 12 16:24:12 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 12 Nov 2024 16:24:12 +0000
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <BYAPR10MB30139742ACA2AB094DA441C9E5592@BYAPR10MB3013.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: Tuesday, November 12, 2024 at 08:23
To: openjfx-dev <openjfx-dev at openjdk.org>, Lukasz Kostyra <lukasz.kostyra at oracle.com>
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.

Lukasz is a member of JavaFX team at Oracle, who has contributed 35
commits [2] to OpenJFX. Lukasz consistently participates in code reviews
of various pull requests, especially in the graphics area.

Votes are due by Nov 26, 2024 at 17:00 UTC.

Only current OpenJFX Reviewers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4]. Nomination to a
project Reviewer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#lkostyra

[2]
https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#three-vote-consensus

[5] https://openjdk.java.net/projects#project-reviewer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/8f2b3391/attachment.htm>

From andy.goryachev at oracle.com  Tue Nov 12 16:27:02 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 12 Nov 2024 16:27:02 +0000
Subject: Prioritized event handlers
In-Reply-To: <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
Message-ID: <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you Michael for answering my questions!

I get from your answers that:

1. the priorities are still needed, in one form or the other.  Adding a different type of the EH (ifUnconsumed) seems to me like a different priority.
2. the problem seems to exist only at the controls level - nothing was mentioned to cause issues related to priority outside of controls.  This seems right, because only in controls we have two (or more) actors engaged in event handling - the application and the skin.
3. dispatching consumed events looks like a bug to all respondents
4, 5.  there seems to be general misunderstanding why I see copyFor() as a big problem.  (Performance is **not** the issue here).

Please correct me if I summarized it incorrectly.

Another interesting observation is that proposals seem to have been replaced by widely different alternatives - ifUnconsumed and event filters.  This might indicate that there is no consensus as of yet, and the discussion must therefore be continued.

The first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level.  If even once scenario exists that does not involve controls, we must find a solution at the event dispatch level.  If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now.

So I would like to ask for clarifications on these three questions:

1. For ifUnconsumed idea: how will it work when both the application and the skin register ifUnconsumed EH?  Or is it only available to one side, but not the other?

2. For event filter in behaviors idea: how does it work when both behavior and the application register an event filter?  and then the skin is changed?  wouldn't we have the same issue?

3. Are there any examples outside of controls where priority inversion happens, or where we need explicit EH priorities for other reasons?

Thank you
-andy






From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, November 8, 2024 at 17:52
To:
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Hi Andy,

1. What happened to this proposal?

I've come to the conclusion that we need something like that, but
probably in a different form. My current thinking is that we don't
need prioritized handlers, but merely a way for interested listeners
to say "I'll take this event, but only if no one else wants it".
A possible API could be something like the following:

target.addEventHandler(KeyEvent.PRESSED, event -> {
    event.ifUnconsumed(evt -> {
        // This will be called after the event has bubbled up
        // without being consumed.
    });
});

This will allow skins to act on events only if user code didn't consume them.

2. Does it make sense to change the API at the EventDispatcher level
when the problem can be easily solved by the InputMap at the Control
level?

Yes, because javafx.controls is not a core part of JavaFX, and it
should never be. People should be free to create their own controls
implementation, or alternative skinning systems. We need to give them
the tools to do so, and not continue the anti-pattern of shifting core
functionality into javafx.controls and special-casing this module even
more than it is already special-cased.

3. dispatching of events that have been consumed (as mentioned in the
earlier discussion)

Probably not necessary. Once an event is consumed, it's gone; we don't
need to dispatch it further.

4. Problem of creating unnecessary clones of events via Event.copyFor()

Unless there is a clear performance problem, I consider any
fundamental change here as a solution in search of a problem.
Events are usually not so plentiful that we're talking about serious
CPU cycles here. The highest-frequency events are probably mouse
events, and they happen at most hundreds of times per second.

5. If we removed the target, then a listener couldn't discern whether
the event was targeted at the receiving node, or at a descendant of
the node.



On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev <andy.goryachev at oracle.com> wrote:
>
> Dear Michael:
> What happened to this proposal?  I would like to restart the discussion, if possible.
>
> More specifically, I would like to discuss the following topics:
>
> the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
> dispatching of events that have been consumed (as mentioned in the earlier discussion)
> problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
> why do we need Event.copyFor() in the first place?  why does Event contain the target??
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/36cf7bd9/attachment-0001.htm>

From mariushanl at web.de  Tue Nov 12 16:43:29 2024
From: mariushanl at web.de (Marius Hanl)
Date: Tue, 12 Nov 2024 16:43:29 +0000
Subject: =?UTF-8?Q?Aw=3A=C2=A0CFV=3A_New_OpenJFX_Committer=3A_Jayathirth_D_V?=
In-Reply-To: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
References: <874b8c74-895f-4dc0-b72a-f6bd476e5def@oracle.com>
Message-ID: <trinity-070e1da8-0e18-4ddf-ae57-2adff7cd35b6-1731429809771@trinity-msg-rest-webde-webde-live-89f5b5b74-5mk6g>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/acf8652b/attachment.htm>

From nlisker at gmail.com  Tue Nov 12 16:50:24 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 12 Nov 2024 18:50:24 +0200
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <BYAPR10MB30139742ACA2AB094DA441C9E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
 <BYAPR10MB30139742ACA2AB094DA441C9E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh8gF5nMW+GA8dVTf8iQjXbq3Z79+awcEDpOLK6mT0AKcg@mail.gmail.com>

Vote: YES

On Tue, Nov 12, 2024 at 6:24?PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Vote: YES
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Tuesday, November 12, 2024 at 08:23
> *To: *openjfx-dev <openjfx-dev at openjdk.org>, Lukasz Kostyra <
> lukasz.kostyra at oracle.com>
> *Subject: *CFV: New OpenJFX Reviewer: Lukasz Kostyra
>
> I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.
>
> Lukasz is a member of JavaFX team at Oracle, who has contributed 35
> commits [2] to OpenJFX. Lukasz consistently participates in code reviews
> of various pull requests, especially in the graphics area.
>
> Votes are due by Nov 26, 2024 at 17:00 UTC.
>
> Only current OpenJFX Reviewers [3] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a
> project Reviewer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#lkostyra
>
> [2]
>
> https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
>
> [5] https://openjdk.java.net/projects#project-reviewer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/8dcb5407/attachment.htm>

From andy.goryachev at oracle.com  Tue Nov 12 17:31:57 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 12 Nov 2024 17:31:57 +0000
Subject: Unconsumed event handlers
In-Reply-To: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
Message-ID: <BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.namprd10.prod.outlook.com>

I am not sure this is the best solution, since it does not solve the problem of multiple actors adding their event handlers.  I do like the idea of prioritized event handlers, because it solves the problem *reliably*.

I think there is no way around it - we need different priorities.  It may be a set or may be a wide range of integers (for the maximum flexibility), but the main idea is that, at least in controls, we have a situation where there are at least these priorities:

- application event filters
- application event handlers
- event handlers set by the skin
- ifUnconsumed-like handlers set by the skin
- ifUnconsumed-like handlers set by the application

Please refer to the table in the "InputMap" section in this document:
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md

(it has more levels due to the desire to define additional levels specific for key mappings, but it's the same idea).

Now, this was proposed in assumption that we only have this problem at the controls level.  I've asked for any examples that suggest otherwise, so far received none, but let's wait a bit more.

My point is that prioritized event handlers solve the issue reliably.  Whether this is implemented in an FX-wide manner, or via the InputMap is less important at this stage.

At this stage, I think it's more important to eliminate the approaches that are guaranteed not to work, and outline the ideas that might work.

What do you think?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Saturday, November 9, 2024 at 23:13
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Unconsumed event handlers
In JavaFX, user code and skins share the same event system. Since
invocation order is fundamentally important for events, this leads to
a lot of problems when skins add event handlers to their controls.
Assume user code adds an event handler to a control, and _then_ sets a
skin that also adds an event handler for the same event. In this case,
the user-provided handler is invoked first. If the skin is set
_first_, the skin gets the first chance to handle the event (see also
https://bugs.openjdk.org/browse/JDK-8231245).

Prioritized event handlers might be a solution for this problem, but
they are quite difficult to get right. Instead, I think we can get
almost all of the benefits using a much simpler solution: unconsumed
event handlers.

We add a new method to the `Event` class:

    <E extends Event> void ifUnconsumed(EventHandler<E> handler)

When an event filter or an event handler receives an event, it calls
the `ifUnconsumed` method with another event handler. Then, after both
phases of event delivery have completed, the list of unconsumed event
handlers associated with the event is invoked in sequence. Once an
unconsumed event handler consumes the event, further propagation is
stopped.

Skins and their behaviors would then always use the unconsumed form of
event handlers:

    // inside a skin/behavior
    control.addEventHandler(
        KeyEvent.KEY_PRESSED,
        e -> e.ifUnconsumed(event -> {
            // act on the event
        }));

This allows user code to see an event during both the capture and
bubble phases without any inteference of the skin or behavior. If user
code doesn't consume the event, the skin or behavior gets to act on
it.

In addition to that, we add a second new method to the `Event` class:

    void discardUnconsumedEventHandlers()

Calling this method in an event handler allows user code to discard
any unconsumed event handlers that have been registered prior. Let's
consider an example where user code wants to prevent a control skin
from acting on the ENTER key event, but it also doesn't want to
consume the event. Adding an event handler to the control, and then
calling `discardUnconsumedEventHandlers()` inside of the event handler
achieves exactly that: it allows the ENTER key event to flow freely
through the control without interacting with it, since its unconsumed
event handlers will never be called.

Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/5e5e56aa/attachment-0001.htm>

From angorya at openjdk.org  Tue Nov 12 17:52:32 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 12 Nov 2024 17:52:32 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v27]
In-Reply-To: <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
Message-ID: <73FL1Cii_myIcXRLHVizv1u_imfVUtdd_jOsfWeyvfc=.9f67e7fe-64e1-4113-9193-635f97f36b2b@github.com>

On Sat, 9 Nov 2024 07:45:19 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED` stage style](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 34 commits:
> 
>  - Merge branch 'master' into feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - add system menu documentation
>  - WindowControlsOverlay snapping
>  - HeaderBar javadoc change
>  - refactor performWindowDrag
>  - HeaderBar changes
>  - EMPTY Dimension2D constant
>  - use CsvSource in HeaderBarTest
>  - stylistic changes
>  - ... and 24 more: https://git.openjdk.org/jfx/compare/d0011b21...65f095ef

modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 133:

> 131: public final class WindowControlsOverlay extends Region {
> 132: 
> 133:     private static final CssMetaData<WindowControlsOverlay, HorizontalDirection> BUTTON_PLACEMENT_METADATA =

BTW, check out `StyleablePropertyFactory`.  It can be used if one doesn't do lazy initialization, or if one doesn't need e.g. `IntegerProperties`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1838534313

From kevin.rushforth at oracle.com  Tue Nov 12 17:56:14 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 12 Nov 2024 09:56:14 -0800
Subject: Prioritized event handlers
In-Reply-To: <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
 <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>

I think this is a good discussion to continue. I have a a couple quick 
comments:

> The first question I would like to resolve is to determine whether the 
> problem exists globally, or only at the controls level.? If even once 
> scenario exists that does not involve controls, we must find a 
> solution at the event dispatch level.? If not - the solution can be at 
> the controls level, and I have proposed a good solution, but it's 
> premature to talk about it right now.

Unless it can be clearly shown that this is a controls-only problem, and 
never will be something that other users of events need to worry about, 
I favor a solution in the event handling mechanism itself rather than 
something controls-specific. So I agree with Michael on this point.

> 4, 5.? there seems to be general misunderstanding why I see copyFor() 
> as a big problem. (Performance is **not** the issue here).

Very likely. I certainly don't see it as a big problem, which suggests I 
might be missing something. I do find it unlikely that we are going to 
change something as fundamental as having a target in the event (which 
is the main reason for using "copyFor").

-- Kevin


On 11/12/2024 8:27 AM, Andy Goryachev wrote:
>
> Thank you Michael for answering my questions!
>
> I get from your answers that:
>
> 1. the priorities are still needed, in one form or the other. Adding a 
> different type of the EH (ifUnconsumed) seems to me like a different 
> priority.
>
> 2. the problem seems to exist only at the controls level - nothing was 
> mentioned to cause issues related to priority outside of controls.? 
> This seems right, because only in controls we have two (or more) 
> actors engaged in event handling - the application and the skin.
>
> 3. dispatching consumed events looks like a bug to all respondents
>
> 4, 5.? there seems to be general misunderstanding why I see copyFor() 
> as a big problem.? (Performance is ***not*** the issue here).
>
> Please correct me if I summarized it incorrectly.
>
> Another interesting observation is that proposals seem to have been 
> replaced by widely different alternatives - ifUnconsumed and event 
> filters.? This might indicate that there is no consensus as of yet, 
> and the discussion must therefore be continued.
>
> The first question I would like to resolve is to determine whether the 
> problem exists globally, or only at the controls level.? If even once 
> scenario exists that does not involve controls, we must find a 
> solution at the event dispatch level.? If not - the solution can be at 
> the controls level, and I have proposed a good solution, but it's 
> premature to talk about it right now.
>
> So I would like to ask for clarifications on these three questions:
>
> 1. For ifUnconsumed idea: how will it work when both the application 
> and the skin register ifUnconsumed EH?? Or is it only available to one 
> side, but not the other?
>
> 2. For event filter in behaviors idea: how does it work when both 
> behavior and the application register an event filter? and then the 
> skin is changed?? wouldn't we have the same issue?
>
> 3. Are there any examples outside of controls where priority inversion 
> happens, or where we need explicit EH priorities for other reasons?
>
> Thank you
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Friday, November 8, 2024 at 17:52
> *To: *
> *Cc: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Re: Prioritized event handlers
>
> Hi Andy,
>
> 1. What happened to this proposal?
>
> I've come to the conclusion that we need something like that, but
> probably in a different form. My current thinking is that we don't
> need prioritized handlers, but merely a way for interested listeners
> to say "I'll take this event, but only if no one else wants it".
> A possible API could be something like the following:
>
> target.addEventHandler(KeyEvent.PRESSED, event -> {
> ??? event.ifUnconsumed(evt -> {
> ??????? // This will be called after the event has bubbled up
> ??????? // without being consumed.
> ??? });
> });
>
> This will allow skins to act on events only if user code didn't 
> consume them.
>
> 2. Does it make sense to change the API at the EventDispatcher level
> when the problem can be easily solved by the InputMap at the Control
> level?
>
> Yes, because javafx.controls is not a core part of JavaFX, and it
> should never be. People should be free to create their own controls
> implementation, or alternative skinning systems. We need to give them
> the tools to do so, and not continue the anti-pattern of shifting core
> functionality into javafx.controls and special-casing this module even
> more than it is already special-cased.
>
> 3. dispatching of events that have been consumed (as mentioned in the
> earlier discussion)
>
> Probably not necessary. Once an event is consumed, it's gone; we don't
> need to dispatch it further.
>
> 4. Problem of creating unnecessary clones of events via Event.copyFor()
>
> Unless there is a clear performance problem, I consider any
> fundamental change here as a solution in search of a problem.
> Events are usually not so plentiful that we're talking about serious
> CPU cycles here. The highest-frequency events are probably mouse
> events, and they happen at most hundreds of times per second.
>
> 5. If we removed the target, then a listener couldn't discern whether
> the event was targeted at the receiving node, or at a descendant of
> the node.
>
>
>
> On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev 
> <andy.goryachev at oracle.com> wrote:
> >
> > Dear Michael:
> > What happened to this proposal?? I would like to restart the 
> discussion, if possible.
> >
> > More specifically, I would like to discuss the following topics:
> >
> > the reason the discussion was started was due to "priority 
> inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' 
> behavior must not depend on sequence of handler registration.? Do we 
> have this problem elsewhere?? In other words, does it make sense to 
> change the API at the EventDispatcher level when the problem can be 
> easily solved by the InputMap at the Control level?
> > dispatching of events that have been consumed (as mentioned in the 
> earlier discussion)
> > problem of creating unnecessary clones of events via 
> Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not 
> consume ENTER KeyEvent when editor ActionEvent is consumed
> > why do we need Event.copyFor() in the first place?? why does Event 
> contain the target??
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/db1cbdc3/attachment-0001.htm>

From martin at martinfox.com  Tue Nov 12 18:14:15 2024
From: martin at martinfox.com (Martin Fox)
Date: Tue, 12 Nov 2024 10:14:15 -0800
Subject: Unconsumed event handlers
In-Reply-To: <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
 <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com>
Message-ID: <C7283E06-EE25-441C-A530-E9FD863E97CA@martinfox.com>

(Here?s hoping this e-mail makes it out to the list. If this is an ongoing problem I might have to switch to using my gmail address.)

I?m writing up some notes to improve the documentation on event dispatch. There seems to be only one rule governing dispatchers and that is ?return null from dispatchEvent to end dispatch?. Beyond that anything goes.

From what I can tell this PR will work if the event passed to the handler is the original event or a copy created using copyFor() and the event returned from dispatchEvent is either the same one that was passed to the handlers or a copy created using copyFor(). These are all reasonable assumptions but there?s nothing in the API that enforces them. In the worst case an event dispatcher may receive an event, pass an entirely new event to one of its handlers, and then return yet another entirely new event from dispatchEvent.

(In the codebase there are three classes that implement EventDispatcher and thirteen that extend an existing EventDispatcher. My guess is that all of them behave reasonably and copy their events using copyFor but I haven?t actually cracked open the code to verify that.)

At this point I?ll resort to hand-waving and speculation. Perhaps this should be divorced from events and reframed in terms of the dispatch process. Instead of ?do this if this event is not consumed? it?s ?do this if the current dispatch ends without consuming an event?. The unconsumed event handlers would then be attached to the dispatch chain instead of the event. And that?s about as far as I?ve thought this through.

Martin

> On Nov 12, 2024, at 5:02?AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> I think `discardUnconsumedEventHandlers` is still a bit unpredictable, as it would depend on handler order.
> 
> The user handler would need to be called *after* Skin/Behavior handlers for it to be able to always discard any ifUnconsumed callbacks.  If the Skin is replaced, then it will re-register handlers and those will then be called last...
> 
> Of course, if we change Behaviors to do their work in filters, then we could get this to work properly.
> 
> --John
> 
> On 10/11/2024 08:12, Michael Strau? wrote:
>> In JavaFX, user code and skins share the same event system. Since
>> invocation order is fundamentally important for events, this leads to
>> a lot of problems when skins add event handlers to their controls.
>> Assume user code adds an event handler to a control, and _then_ sets a
>> skin that also adds an event handler for the same event. In this case,
>> the user-provided handler is invoked first. If the skin is set
>> _first_, the skin gets the first chance to handle the event (see also
>> https://bugs.openjdk.org/browse/JDK-8231245).
>> 
>> Prioritized event handlers might be a solution for this problem, but
>> they are quite difficult to get right. Instead, I think we can get
>> almost all of the benefits using a much simpler solution: unconsumed
>> event handlers.
>> 
>> We add a new method to the `Event` class:
>> 
>>     <E extends Event> void ifUnconsumed(EventHandler<E> handler)
>> 
>> When an event filter or an event handler receives an event, it calls
>> the `ifUnconsumed` method with another event handler. Then, after both
>> phases of event delivery have completed, the list of unconsumed event
>> handlers associated with the event is invoked in sequence. Once an
>> unconsumed event handler consumes the event, further propagation is
>> stopped.
>> 
>> Skins and their behaviors would then always use the unconsumed form of
>> event handlers:
>> 
>>     // inside a skin/behavior
>>     control.addEventHandler(
>>         KeyEvent.KEY_PRESSED,
>>         e -> e.ifUnconsumed(event -> {
>>             // act on the event
>>         }));
>> 
>> This allows user code to see an event during both the capture and
>> bubble phases without any inteference of the skin or behavior. If user
>> code doesn't consume the event, the skin or behavior gets to act on
>> it.
>> 
>> In addition to that, we add a second new method to the `Event` class:
>> 
>>     void discardUnconsumedEventHandlers()
>> 
>> Calling this method in an event handler allows user code to discard
>> any unconsumed event handlers that have been registered prior. Let's
>> consider an example where user code wants to prevent a control skin
>> from acting on the ENTER key event, but it also doesn't want to
>> consume the event. Adding an event handler to the control, and then
>> calling `discardUnconsumedEventHandlers()` inside of the event handler
>> achieves exactly that: it allows the ENTER key event to flow freely
>> through the control without interacting with it, since its unconsumed
>> event handlers will never be called.
>> 
>> Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633


From nlisker at gmail.com  Tue Nov 12 18:46:22 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 12 Nov 2024 20:46:22 +0200
Subject: Prioritized event handlers
In-Reply-To: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
 <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>
Message-ID: <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>

I'd like to understand the focus and event handling problem better. If I
have a focused TextField, all key events go to it. If I have a Spinner,
which is a TextField with 2 Buttons, it is focused as a single unit and
consumes key events whether they are aimed at the text field or the buttons
(I assume the buttons handle arrow up/down keys?). If I have a
ClolorPicker, it is not focused as a single unit - it has sliders, buttons,
text fields and other things, which can be focused individually.

What I'm trying to find out is what is "the primitive" in the focus/event
handling plan. A TextField and a Spinner are treated as primitives, but a
ColorPicker and a DatePicker are not. Where does the line pass? If I'm a
controls author, can I create a Spinner that allows focusing/event-handling
the text field and the buttons separately, like ColorPicker allows? In this
case, Spinner is not a "primitive" control.

On Tue, Nov 12, 2024 at 7:56?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I think this is a good discussion to continue. I have a a couple quick
> comments:
>
> The first question I would like to resolve is to determine whether the
> problem exists globally, or only at the controls level.  If even once
> scenario exists that does not involve controls, we must find a solution at
> the event dispatch level.  If not - the solution can be at the controls
> level, and I have proposed a good solution, but it's premature to talk
> about it right now.
>
>
> Unless it can be clearly shown that this is a controls-only problem, and
> never will be something that other users of events need to worry about, I
> favor a solution in the event handling mechanism itself rather than
> something controls-specific. So I agree with Michael on this point.
>
> 4, 5.  there seems to be general misunderstanding why I see copyFor() as a
> big problem.  (Performance is **not** the issue here).
>
>
> Very likely. I certainly don't see it as a big problem, which suggests I
> might be missing something. I do find it unlikely that we are going to
> change something as fundamental as having a target in the event (which is
> the main reason for using "copyFor").
>
> -- Kevin
>
>
> On 11/12/2024 8:27 AM, Andy Goryachev wrote:
>
> Thank you Michael for answering my questions!
>
>
>
> I get from your answers that:
>
>
>
> 1. the priorities are still needed, in one form or the other.  Adding a
> different type of the EH (ifUnconsumed) seems to me like a different
> priority.
>
> 2. the problem seems to exist only at the controls level - nothing was
> mentioned to cause issues related to priority outside of controls.  This
> seems right, because only in controls we have two (or more) actors engaged
> in event handling - the application and the skin.
>
> 3. dispatching consumed events looks like a bug to all respondents
>
> 4, 5.  there seems to be general misunderstanding why I see copyFor() as a
> big problem.  (Performance is ***not*** the issue here).
>
>
>
> Please correct me if I summarized it incorrectly.
>
>
>
> Another interesting observation is that proposals seem to have been
> replaced by widely different alternatives - ifUnconsumed and event
> filters.  This might indicate that there is no consensus as of yet, and the
> discussion must therefore be continued.
>
>
>
> The first question I would like to resolve is to determine whether the
> problem exists globally, or only at the controls level.  If even once
> scenario exists that does not involve controls, we must find a solution at
> the event dispatch level.  If not - the solution can be at the controls
> level, and I have proposed a good solution, but it's premature to talk
> about it right now.
>
>
>
> So I would like to ask for clarifications on these three questions:
>
>
>
> 1. For ifUnconsumed idea: how will it work when both the application and
> the skin register ifUnconsumed EH?  Or is it only available to one side,
> but not the other?
>
>
>
> 2. For event filter in behaviors idea: how does it work when both behavior
> and the application register an event filter?  and then the skin is
> changed?  wouldn't we have the same issue?
>
>
>
> 3. Are there any examples outside of controls where priority inversion
> happens, or where we need explicit EH priorities for other reasons?
>
>
>
> Thank you
>
> -andy
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau?
> <michaelstrau2 at gmail.com> <michaelstrau2 at gmail.com>
> *Date: *Friday, November 8, 2024 at 17:52
> *To: *
> *Cc: *openjfx-dev <openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org>
> *Subject: *Re: Prioritized event handlers
>
> Hi Andy,
>
> 1. What happened to this proposal?
>
> I've come to the conclusion that we need something like that, but
> probably in a different form. My current thinking is that we don't
> need prioritized handlers, but merely a way for interested listeners
> to say "I'll take this event, but only if no one else wants it".
> A possible API could be something like the following:
>
> target.addEventHandler(KeyEvent.PRESSED, event -> {
>     event.ifUnconsumed(evt -> {
>         // This will be called after the event has bubbled up
>         // without being consumed.
>     });
> });
>
> This will allow skins to act on events only if user code didn't consume
> them.
>
> 2. Does it make sense to change the API at the EventDispatcher level
> when the problem can be easily solved by the InputMap at the Control
> level?
>
> Yes, because javafx.controls is not a core part of JavaFX, and it
> should never be. People should be free to create their own controls
> implementation, or alternative skinning systems. We need to give them
> the tools to do so, and not continue the anti-pattern of shifting core
> functionality into javafx.controls and special-casing this module even
> more than it is already special-cased.
>
> 3. dispatching of events that have been consumed (as mentioned in the
> earlier discussion)
>
> Probably not necessary. Once an event is consumed, it's gone; we don't
> need to dispatch it further.
>
> 4. Problem of creating unnecessary clones of events via Event.copyFor()
>
> Unless there is a clear performance problem, I consider any
> fundamental change here as a solution in search of a problem.
> Events are usually not so plentiful that we're talking about serious
> CPU cycles here. The highest-frequency events are probably mouse
> events, and they happen at most hundreds of times per second.
>
> 5. If we removed the target, then a listener couldn't discern whether
> the event was targeted at the receiving node, or at a descendant of
> the node.
>
>
>
> On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev <andy.goryachev at oracle.com>
> <andy.goryachev at oracle.com> wrote:
> >
> > Dear Michael:
> > What happened to this proposal?  I would like to restart the discussion,
> if possible.
> >
> > More specifically, I would like to discuss the following topics:
> >
> > the reason the discussion was started was due to "priority inversion"
> problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not
> depend on sequence of handler registration.  Do we have this problem
> elsewhere?  In other words, does it make sense to change the API at the
> EventDispatcher level when the problem can be easily solved by the InputMap
> at the Control level?
> > dispatching of events that have been consumed (as mentioned in the
> earlier discussion)
> > problem of creating unnecessary clones of events via Event.copyFor(),
> leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent
> when editor ActionEvent is consumed
> > why do we need Event.copyFor() in the first place?  why does Event
> contain the target??
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/f6393b58/attachment-0001.htm>

From john.hendrikx at gmail.com  Tue Nov 12 18:58:22 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 12 Nov 2024 19:58:22 +0100
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <a617348d-2e4b-4760-88e3-519bda7bf803@gmail.com>

Vote: YES

On 12/11/2024 17:22, Kevin Rushforth wrote:
> I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.
>
> Lukasz is a member of JavaFX team at Oracle, who has contributed 35 
> commits [2] to OpenJFX. Lukasz consistently participates in code 
> reviews of various pull requests, especially in the graphics area.
>
> Votes are due by Nov 26, 2024 at 17:00 UTC.
>
> Only current OpenJFX Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a 
> project Reviewer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#lkostyra
>
> [2] 
> https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits
>
> [3] https://openjdk.java.net/census#openjfx
>
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
>
> [5] https://openjdk.java.net/projects#project-reviewer
>

From john.hendrikx at gmail.com  Tue Nov 12 19:06:33 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 12 Nov 2024 20:06:33 +0100
Subject: Unconsumed event handlers
In-Reply-To: <C7283E06-EE25-441C-A530-E9FD863E97CA@martinfox.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
 <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com>
 <C7283E06-EE25-441C-A530-E9FD863E97CA@martinfox.com>
Message-ID: <e2ee1604-cb7e-4f80-9ac9-10efbcb61bf7@gmail.com>

Hi Martin,

I'm still unsure how this exactly is supposed to go wrong.

Whenever you dispatch a new event, you should always follow-up and check 
if it was consumed after the dispatch finishes.? If it is, then you mark 
the triggering event also as consumed.? If this is done consistently 
everywhere, then the consumed flag should function as expected or not?

Code that does is simply wrong:

 ?????? e -> {
 ???????????? node.fireEvent(new KeyEvent(...));? // can't check if it 
was consumed!
 ???????????? // consume "e" or not?
 ?????? }

The above is?a bug, and needs to be fixed if it is present in FX.

So the way I see it, every time you fire a new event in response to 
another, it is your responsibility to ensure that you check if the new 
event was consumed, and if it was, to mark the initial event as consumed 
as well.? Following this everywhere should make the consumed flag work 
as expected.

What am I missing?

--John

On 12/11/2024 19:14, Martin Fox wrote:
> (Here?s hoping this e-mail makes it out to the list. If this is an ongoing problem I might have to switch to using my gmail address.)
>
> I?m writing up some notes to improve the documentation on event dispatch. There seems to be only one rule governing dispatchers and that is ?return null from dispatchEvent to end dispatch?. Beyond that anything goes.
>
>  From what I can tell this PR will work if the event passed to the handler is the original event or a copy created using copyFor() and the event returned from dispatchEvent is either the same one that was passed to the handlers or a copy created using copyFor(). These are all reasonable assumptions but there?s nothing in the API that enforces them. In the worst case an event dispatcher may receive an event, pass an entirely new event to one of its handlers, and then return yet another entirely new event from dispatchEvent.
>
> (In the codebase there are three classes that implement EventDispatcher and thirteen that extend an existing EventDispatcher. My guess is that all of them behave reasonably and copy their events using copyFor but I haven?t actually cracked open the code to verify that.)
>
> At this point I?ll resort to hand-waving and speculation. Perhaps this should be divorced from events and reframed in terms of the dispatch process. Instead of ?do this if this event is not consumed? it?s ?do this if the current dispatch ends without consuming an event?. The unconsumed event handlers would then be attached to the dispatch chain instead of the event. And that?s about as far as I?ve thought this through.
>
> Martin
>
>> On Nov 12, 2024, at 5:02?AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
>>
>> I think `discardUnconsumedEventHandlers` is still a bit unpredictable, as it would depend on handler order.
>>
>> The user handler would need to be called *after* Skin/Behavior handlers for it to be able to always discard any ifUnconsumed callbacks.  If the Skin is replaced, then it will re-register handlers and those will then be called last...
>>
>> Of course, if we change Behaviors to do their work in filters, then we could get this to work properly.
>>
>> --John
>>
>> On 10/11/2024 08:12, Michael Strau? wrote:
>>> In JavaFX, user code and skins share the same event system. Since
>>> invocation order is fundamentally important for events, this leads to
>>> a lot of problems when skins add event handlers to their controls.
>>> Assume user code adds an event handler to a control, and _then_ sets a
>>> skin that also adds an event handler for the same event. In this case,
>>> the user-provided handler is invoked first. If the skin is set
>>> _first_, the skin gets the first chance to handle the event (see also
>>> https://bugs.openjdk.org/browse/JDK-8231245).
>>>
>>> Prioritized event handlers might be a solution for this problem, but
>>> they are quite difficult to get right. Instead, I think we can get
>>> almost all of the benefits using a much simpler solution: unconsumed
>>> event handlers.
>>>
>>> We add a new method to the `Event` class:
>>>
>>>      <E extends Event> void ifUnconsumed(EventHandler<E> handler)
>>>
>>> When an event filter or an event handler receives an event, it calls
>>> the `ifUnconsumed` method with another event handler. Then, after both
>>> phases of event delivery have completed, the list of unconsumed event
>>> handlers associated with the event is invoked in sequence. Once an
>>> unconsumed event handler consumes the event, further propagation is
>>> stopped.
>>>
>>> Skins and their behaviors would then always use the unconsumed form of
>>> event handlers:
>>>
>>>      // inside a skin/behavior
>>>      control.addEventHandler(
>>>          KeyEvent.KEY_PRESSED,
>>>          e -> e.ifUnconsumed(event -> {
>>>              // act on the event
>>>          }));
>>>
>>> This allows user code to see an event during both the capture and
>>> bubble phases without any inteference of the skin or behavior. If user
>>> code doesn't consume the event, the skin or behavior gets to act on
>>> it.
>>>
>>> In addition to that, we add a second new method to the `Event` class:
>>>
>>>      void discardUnconsumedEventHandlers()
>>>
>>> Calling this method in an event handler allows user code to discard
>>> any unconsumed event handlers that have been registered prior. Let's
>>> consider an example where user code wants to prevent a control skin
>>> from acting on the ENTER key event, but it also doesn't want to
>>> consume the event. Adding an event handler to the control, and then
>>> calling `discardUnconsumedEventHandlers()` inside of the event handler
>>> achieves exactly that: it allows the ENTER key event to flow freely
>>> through the control without interacting with it, since its unconsumed
>>> event handlers will never be called.
>>>
>>> Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633

From philip.race at oracle.com  Tue Nov 12 19:14:56 2024
From: philip.race at oracle.com (Philip Race)
Date: Tue, 12 Nov 2024 11:14:56 -0800
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <1cf28582-6aca-4815-85cd-a440ba3d4c47@oracle.com>

Vote: yes

-phil.

From john.hendrikx at gmail.com  Tue Nov 12 19:27:28 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 12 Nov 2024 20:27:28 +0100
Subject: Prioritized event handlers
In-Reply-To: <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
 <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>
 <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
Message-ID: <e154a753-6fa0-4e24-8403-5a761006aeb9@gmail.com>

On 12/11/2024 19:46, Nir Lisker wrote:
> I'd like to understand the focus and event handling problem better. If 
> I have a focused TextField, all key events go to it. If I have a 
> Spinner, which is a TextField with 2 Buttons, it is focused as a 
> single unit and consumes key events whether they are aimed at the text 
> field or the buttons (I assume the buttons handle arrow up/down 
> keys?). If I have a ClolorPicker, it is not focused as a single unit - 
> it has sliders, buttons, text fields and other things, which can be 
> focused individually.

For Spinner, all key events go to the main Spinner control, including 
the arrow keys.? This is because KeyEvents are always dispatched to 
Scene#focusOwner which the user should never see to be something other 
than the Spinner (ie. it shouldn't ever be Spinner Up Button).? The 
Behavior installed should act first on any such keys, including the 
arrow keys.? The reason there are no arrow key handlers on the buttons 
is because the buttons?are Skin specific, and so handling them there 
would break the Spinner's intended functionality if those buttons don't 
exist or are implemented differently.? The arrow keys will work 
regardless if there are buttons or not, and so it is not a? good idea to 
have the Skin handle them (aside from the fact that the Behavior should 
be deciding such matters, not the Skin).

However, if the TextField has focus (it really doesn't have it, hence 
the FakeFocusTextField) then to make the TextField actually work, the 
KeyEvents that are still going to Spinner must be forwarded to the inner 
TextField.? This is a Skin reponsibility as only the skin knows where 
those events could possibly go (if there is no TextField, then nothing 
needs forwarding).? The current implementation however does this in a 
really round-about way, and will resend the KeyEvent from the top of the 
Scene graph all the way back to the inner TextField as target -- this 
means any handlers in between see these events twice.? What should have 
been done is that the event is only forwarded locally (I tested this in 
a draft PR, and that works splendidly).? Michael's proposal essentially 
makes this standard functionality, so you don't need to do any manual 
forwarding anymore.

ColorPicker is probably also faking the focus on its individual 
components (I didn't check), but if it is supposed to be a reusable 
integrated Control, then from the focus owner perspective, only 
ColorPicker ever has the focus (of course, if it opens a PopUp, that's a 
new Scene, which can have its own focus owner).

>
> What I'm trying to find out is what is "the primitive" in the 
> focus/event handling plan. A TextField and a Spinner are treated as 
> primitives, but a ColorPicker and a DatePicker are not. Where does the 
> line pass? If I'm a controls author, can I create a Spinner that 
> allows focusing/event-handling the text field and the buttons 
> separately,?like ColorPicker allows? In this case, Spinner is not a 
> "primitive"?control.

IMHO ColorPicker and DatePicker are also primitive controls.? I want to 
be able to tab passed one without going into its inner buttons/fields, 
same as combo box.? If they open a Popup (after pressing ENTER or SPACE) 
then the whole control is still focused, but there is a 2nd focus inside 
the new popup created (we wouldn't want the main control to lose its 
focus border as that's really confusing).? For Spinner for example, when 
its text field has the focus, the focus border is around the entire 
control (including the arrow buttons), not just on the TextField area.

--John

>
> On Tue, Nov 12, 2024 at 7:56?PM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     I think this is a good discussion to continue. I have a a couple
>     quick comments:
>
>>     The first question I would like to resolve is to determine
>>     whether the problem exists globally, or only at the controls
>>     level.? If even once scenario exists that does not involve
>>     controls, we must find a solution at the event dispatch level.?
>>     If not - the solution can be at the controls level, and I have
>>     proposed a good solution, but it's premature to talk about it
>>     right now.
>
>     Unless it can be clearly shown that this is a controls-only
>     problem, and never will be something that other users of events
>     need to worry about, I favor a solution in the event handling
>     mechanism itself rather than something controls-specific. So I
>     agree with Michael on this point.
>
>>     4, 5.? there seems to be general misunderstanding why I see
>>     copyFor() as a big problem. (Performance is **not** the issue here).
>
>     Very likely. I certainly don't see it as a big problem, which
>     suggests I might be missing something. I do find it unlikely that
>     we are going to change something as fundamental as having a target
>     in the event (which is the main reason for using "copyFor").
>
>     -- Kevin
>
>
>     On 11/12/2024 8:27 AM, Andy Goryachev wrote:
>>
>>     Thank you Michael for answering my questions!
>>
>>     I get from your answers that:
>>
>>     1. the priorities are still needed, in one form or the other.?
>>     Adding a different type of the EH (ifUnconsumed) seems to me like
>>     a different priority.
>>
>>     2. the problem seems to exist only at the controls level -
>>     nothing was mentioned to cause issues related to priority outside
>>     of controls.? This seems right, because only in controls we have
>>     two (or more) actors engaged in event handling - the application
>>     and the skin.
>>
>>     3. dispatching consumed events looks like a bug to all respondents
>>
>>     4, 5. there seems to be general misunderstanding why I see
>>     copyFor() as a big problem.? (Performance is ***not*** the issue
>>     here).
>>
>>     Please correct me if I summarized it incorrectly.
>>
>>     Another interesting observation is that proposals seem to have
>>     been replaced by widely different alternatives - ifUnconsumed and
>>     event filters.? This might indicate that there is no consensus as
>>     of yet, and the discussion must therefore be continued.
>>
>>     The first question I would like to resolve is to determine
>>     whether the problem exists globally, or only at the controls
>>     level.? If even once scenario exists that does not involve
>>     controls, we must find a solution at the event dispatch level.?
>>     If not - the solution can be at the controls level, and I have
>>     proposed a good solution, but it's premature to talk about it
>>     right now.
>>
>>     So I would like to ask for clarifications on these three questions:
>>
>>     1. For ifUnconsumed idea: how will it work when both the
>>     application and the skin register ifUnconsumed EH? Or is it only
>>     available to one side, but not the other?
>>
>>     2. For event filter in behaviors idea: how does it work when both
>>     behavior and the application register an event filter?? and then
>>     the skin is changed? wouldn't we have the same issue?
>>
>>     3. Are there any examples outside of controls where priority
>>     inversion happens, or where we need explicit EH priorities for
>>     other reasons?
>>
>>     Thank you
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau?
>>     <michaelstrau2 at gmail.com> <mailto:michaelstrau2 at gmail.com>
>>     *Date: *Friday, November 8, 2024 at 17:52
>>     *To: *
>>     *Cc: *openjfx-dev <openjfx-dev at openjdk.org>
>>     <mailto:openjfx-dev at openjdk.org>
>>     *Subject: *Re: Prioritized event handlers
>>
>>     Hi Andy,
>>
>>     1. What happened to this proposal?
>>
>>     I've come to the conclusion that we need something like that, but
>>     probably in a different form. My current thinking is that we don't
>>     need prioritized handlers, but merely a way for interested listeners
>>     to say "I'll take this event, but only if no one else wants it".
>>     A possible API could be something like the following:
>>
>>     target.addEventHandler(KeyEvent.PRESSED, event -> {
>>     ??? event.ifUnconsumed(evt -> {
>>     ??????? // This will be called after the event has bubbled up
>>     ??????? // without being consumed.
>>     ??? });
>>     });
>>
>>     This will allow skins to act on events only if user code didn't
>>     consume them.
>>
>>     2. Does it make sense to change the API at the EventDispatcher level
>>     when the problem can be easily solved by the InputMap at the Control
>>     level?
>>
>>     Yes, because javafx.controls is not a core part of JavaFX, and it
>>     should never be. People should be free to create their own controls
>>     implementation, or alternative skinning systems. We need to give them
>>     the tools to do so, and not continue the anti-pattern of shifting
>>     core
>>     functionality into javafx.controls and special-casing this module
>>     even
>>     more than it is already special-cased.
>>
>>     3. dispatching of events that have been consumed (as mentioned in the
>>     earlier discussion)
>>
>>     Probably not necessary. Once an event is consumed, it's gone; we
>>     don't
>>     need to dispatch it further.
>>
>>     4. Problem of creating unnecessary clones of events via
>>     Event.copyFor()
>>
>>     Unless there is a clear performance problem, I consider any
>>     fundamental change here as a solution in search of a problem.
>>     Events are usually not so plentiful that we're talking about serious
>>     CPU cycles here. The highest-frequency events are probably mouse
>>     events, and they happen at most hundreds of times per second.
>>
>>     5. If we removed the target, then a listener couldn't discern whether
>>     the event was targeted at the receiving node, or at a descendant of
>>     the node.
>>
>>
>>
>>     On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev
>>     <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>>     >
>>     > Dear Michael:
>>     > What happened to this proposal?? I would like to restart the
>>     discussion, if possible.
>>     >
>>     > More specifically, I would like to discuss the following topics:
>>     >
>>     > the reason the discussion was started was due to "priority
>>     inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls'
>>     behavior must not depend on sequence of handler registration.? Do
>>     we have this problem elsewhere?? In other words, does it make
>>     sense to change the API at the EventDispatcher level when the
>>     problem can be easily solved by the InputMap at the Control level?
>>     > dispatching of events that have been consumed (as mentioned in
>>     the earlier discussion)
>>     > problem of creating unnecessary clones of events via
>>     Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not
>>     consume ENTER KeyEvent when editor ActionEvent is consumed
>>     > why do we need Event.copyFor() in the first place?? why does
>>     Event contain the target??
>>     >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241112/f817fb37/attachment-0001.htm>

From michaelstrau2 at gmail.com  Tue Nov 12 19:32:01 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 12 Nov 2024 20:32:01 +0100
Subject: Prioritized event handlers
In-Reply-To: <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
 <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>
 <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
Message-ID: <CAJEpuXT_eckaWLkMdnNwt9nF+XrOOf5MmKP7Z-G8FUFmsqsNGA@mail.gmail.com>

I would encourage to continue this discussion in the focus delegation
thread, not in the prioritized event handlers thread.



On Tue, Nov 12, 2024 at 8:13?PM Nir Lisker <nlisker at gmail.com> wrote:
>
> I'd like to understand the focus and event handling problem better. If I have a focused TextField, all key events go to it. If I have a Spinner, which is a TextField with 2 Buttons, it is focused as a single unit and consumes key events whether they are aimed at the text field or the buttons (I assume the buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not focused as a single unit - it has sliders, buttons, text fields and other things, which can be focused individually.
>
> What I'm trying to find out is what is "the primitive" in the focus/event handling plan. A TextField and a Spinner are treated as primitives, but a ColorPicker and a DatePicker are not. Where does the line pass? If I'm a controls author, can I create a Spinner that allows focusing/event-handling the text field and the buttons separately, like ColorPicker allows? In this case, Spinner is not a "primitive" control.
>

From andy.goryachev at oracle.com  Tue Nov 12 19:37:41 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 12 Nov 2024 19:37:41 +0000
Subject: Prioritized event handlers
In-Reply-To: <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <BL3PR10MB6185AAAD30E56D358CF52E02E5532@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXRvx0OVvowPfcrNWJ3RZnaGWo0xX2kmPeuEM3+79W0N7w@mail.gmail.com>
 <BYAPR10MB30137BABFCA3C5BD09C30222E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com>
 <CA+0ynh89-CukAeSXw3Z_E2UOjgWK9HfKP0VC9seCAJZv8FSWmQ@mail.gmail.com>
Message-ID: <BYAPR10MB30131ABA79787A42E57990E1E5592@BYAPR10MB3013.namprd10.prod.outlook.com>

I'd like to understand that too, though the question here might be a slightly different topic (maybe for a separate mail thread).

The way I look at the problem of using controls as part of other controls (e.g. a TextField inside a Spinner) is that the inner is no longer a fully functional control, in the sense that it's behavior is different, and governed by the parent control.

I tried to clarify the separation between various parts in my InputMap proposal (we are not discussing that yet), look at the table in the "Description" section
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md

Basically, the control is a fa?ade that hides its internal structure.  So when the application is dealing with the Spinner, it should not deal with the TextField, unless there are public APIs in the Spinner just for that.  How the Spinner works is determined by its skin - which can be anything, it can be a 3D knob in some virtual reality with no TextField whatsoever!  (Not the case of Spinner, as it actually publishes the TextArea via its getEditor() API.

So when we decide to use TextField in a specific SpinnerSkin, we need to modify the way the TextField (being a part of the whole and not the whole) reacts to the external events.  The same goes for decorations, including focus decorations.  To show the focused spinner we now draw the focus border around the spinner, not the TextArea.  So we need a way to reconfigure the event handling behavior of the TexTField used inside of the Spinner.

Using the InputMap, it's easy to do without subclassing, by simply modifying the InputMap of the inner TextArea.   Right now, we have to jump through a number of hoops with colorful names like setFakeFocus() and so on.

What I am trying to get to is that, once the control is a part of another control, it's behavior ("controller" in terms of MVC paradigm) changes, may be even gets substituted by the "controller" of the parent Control.  The parent Control is solely responsible for the new behavior, or we going to have tug of war between two parties.

I guess my point is - we need a way to customize the behavior, it's useful to both application developers, custom control developers, and the internal skin design, and it's really easy to do with an InputMap.

What do you think?

-andy






From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Date: Tuesday, November 12, 2024 at 10:47
To: Kevin Rushforth <kevin.rushforth at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
I'd like to understand the focus and event handling problem better. If I have a focused TextField, all key events go to it. If I have a Spinner, which is a TextField with 2 Buttons, it is focused as a single unit and consumes key events whether they are aimed at the text field or the buttons (I assume the buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not focused as a single unit - it has sliders, buttons, text fields and other things, which can be focused individually.

What I'm trying to find out is what is "the primitive" in the focus/event handling plan. A TextField and a Spinner are treated as primitives, but a ColorPicker and a DatePicker are not. Where does the line pass? If I'm a controls author, can I create a Spinner that allows focusing/event-handling the text field and the buttons separately, like ColorPicker allows? In this case, Spinner is not a "primitive" control.

On Tue, Nov 12, 2024 at 7:56?PM Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>> wrote:
I think this is a good discussion to continue. I have a a couple quick comments:


The first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level.  If even once scenario exists that does not involve controls, we must find a solution at the event dispatch level.  If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now.

Unless it can be clearly shown that this is a controls-only problem, and never will be something that other users of events need to worry about, I favor a solution in the event handling mechanism itself rather than something controls-specific. So I agree with Michael on this point.


4, 5.  there seems to be general misunderstanding why I see copyFor() as a big problem.  (Performance is **not** the issue here).

Very likely. I certainly don't see it as a big problem, which suggests I might be missing something. I do find it unlikely that we are going to change something as fundamental as having a target in the event (which is the main reason for using "copyFor").

-- Kevin

On 11/12/2024 8:27 AM, Andy Goryachev wrote:
Thank you Michael for answering my questions!

I get from your answers that:

1. the priorities are still needed, in one form or the other.  Adding a different type of the EH (ifUnconsumed) seems to me like a different priority.
2. the problem seems to exist only at the controls level - nothing was mentioned to cause issues related to priority outside of controls.  This seems right, because only in controls we have two (or more) actors engaged in event handling - the application and the skin.
3. dispatching consumed events looks like a bug to all respondents
4, 5.  there seems to be general misunderstanding why I see copyFor() as a big problem.  (Performance is **not** the issue here).

Please correct me if I summarized it incorrectly.

Another interesting observation is that proposals seem to have been replaced by widely different alternatives - ifUnconsumed and event filters.  This might indicate that there is no consensus as of yet, and the discussion must therefore be continued.

The first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level.  If even once scenario exists that does not involve controls, we must find a solution at the event dispatch level.  If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now.

So I would like to ask for clarifications on these three questions:

1. For ifUnconsumed idea: how will it work when both the application and the skin register ifUnconsumed EH?  Or is it only available to one side, but not the other?

2. For event filter in behaviors idea: how does it work when both behavior and the application register an event filter?  and then the skin is changed?  wouldn't we have the same issue?

3. Are there any examples outside of controls where priority inversion happens, or where we need explicit EH priorities for other reasons?

Thank you
-andy






From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Friday, November 8, 2024 at 17:52
To:
Cc: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Hi Andy,

1. What happened to this proposal?

I've come to the conclusion that we need something like that, but
probably in a different form. My current thinking is that we don't
need prioritized handlers, but merely a way for interested listeners
to say "I'll take this event, but only if no one else wants it".
A possible API could be something like the following:

target.addEventHandler(KeyEvent.PRESSED, event -> {
    event.ifUnconsumed(evt -> {
        // This will be called after the event has bubbled up
        // without being consumed.
    });
});

This will allow skins to act on events only if user code didn't consume them.

2. Does it make sense to change the API at the EventDispatcher level
when the problem can be easily solved by the InputMap at the Control
level?

Yes, because javafx.controls is not a core part of JavaFX, and it
should never be. People should be free to create their own controls
implementation, or alternative skinning systems. We need to give them
the tools to do so, and not continue the anti-pattern of shifting core
functionality into javafx.controls and special-casing this module even
more than it is already special-cased.

3. dispatching of events that have been consumed (as mentioned in the
earlier discussion)

Probably not necessary. Once an event is consumed, it's gone; we don't
need to dispatch it further.

4. Problem of creating unnecessary clones of events via Event.copyFor()

Unless there is a clear performance problem, I consider any
fundamental change here as a solution in search of a problem.
Events are usually not so plentiful that we're talking about serious
CPU cycles here. The highest-frequency events are probably mouse
events, and they happen at most hundreds of times per second.

5. If we removed the target, then a listener couldn't discern whether
the event was targeted at the receiving node, or at a descendant of
the node.



On Thu, Nov 7, 2024 at 1:03?AM Andy Goryachev <andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com> wrote:
>
> Dear Michael:
> What happened to this proposal?  I would like to restart the discussion, if possible.
>
> More specifically, I would like to discuss the following topics:
>
> the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on sequence of handler registration.  Do we have this problem elsewhere?  In other words, does it make sense to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?
> dispatching of events that have been consumed (as mentioned in the earlier discussion)
> problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
> why do we need Event.copyFor() in the first place?  why does Event contain the target??
>

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

From michaelstrau2 at gmail.com  Tue Nov 12 19:42:49 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 12 Nov 2024 20:42:49 +0100
Subject: Focus delegation API
In-Reply-To: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
Message-ID: <CAJEpuXRm+j-8xpMtP7Kn9Bfn_17+KGAS2xudQmEohvnYxHZ1MQ@mail.gmail.com>

Responding to Nir's questions in this thread.

> I'd like to understand the focus and event handling problem better. If I have a focused TextField, all key events go to it. If I have a Spinner, which is a TextField with 2 Buttons, it is focused as a single unit and consumes key events whether they are aimed at the text field or the buttons (I assume the buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not focused as a single unit - it has sliders, buttons, text fields and other things, which can be focused individually.
>
> What I'm trying to find out is what is "the primitive" in the focus/event handling plan. A TextField and a Spinner are treated as primitives, but a ColorPicker and a DatePicker are not. Where does the line pass? If I'm a controls author, can I create a Spinner that allows focusing/event-handling the text field and the buttons separately, like ColorPicker allows? In this case, Spinner is not a "primitive" control.


I would say that the line is wherever you draw it. Some controls are
monoliths, some are composites, some are a mixture of both.

Think of Button: it has a user-configurable `graphic` property that
accepts any Node, and both are independently focusable.

You can imagine creating a control that is mostly a monolith (like
Spinner), but has a "hole" that can be filled with any content by
users.

The proposed focus delegation API allows you to do any of that.

From john.hendrikx at gmail.com  Tue Nov 12 20:18:02 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 12 Nov 2024 21:18:02 +0100
Subject: Unconsumed event handlers
In-Reply-To: <BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
 <BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <84eda7bc-1027-465e-80df-a28d4bf69256@gmail.com>


On 12/11/2024 18:31, Andy Goryachev wrote:
>
> I am not sure this is the best solution, since it does not solve the 
> problem of multiple actors adding their event handlers. I do like the 
> idea of prioritized event handlers, because it solves the problem 
> **reliably**.
>
> I think there is no way around it - we need different priorities.? It 
> may be a set or may be a wide range of integers (for the maximum 
> flexibility), but the main idea is that, at least in controls, we have 
> a situation where there are at least these priorities:
>
I think if we can find a solution that doesn't require priorities that 
it should by far be preferred.? You have to think more from a user 
perspective.? They have a Button, and they add an Event Handler to do 
something with the SPACE key.? They run their code, and they find SPACE 
just disappears and never arrives at their handler.? However, if they 
add the handler in the Constructor of a Button subclass, or before the 
Skin is applied, then the handler does work.? There should not be a 
difference for the user, because the Event Handler system does not 
stipulate that there are internal handlers that are sharing this 
infrastructure; for the user the system looks like it is available 
solely for their use.

Let's say you now add priorities.? What possible reason could a user 
have for adding an event handler (for SPACE key) that wouldn't work (too 
low priority) or doesn't work reliably (equal priority)?? In other 
words, the only relevant priority for users is the one that will make 
their handler work, which more often than not will be MAX.

Now let's say we have a Node, and we add several handlers:

 ???? Event.ANY (+10)
 ???? KeyEvent.KEY_ANY (+20)
 ???? KeyEvent.KEY_PRESSED (0)

What order are they going to be called?? Without priorities that would 
be KEY_PRESSED, KEY_ANY, ANY

Now let's have a hierarchy of Nodes, A -> B -> C -- I add the following 
handlers:

 ????? A: KeyEvent.KEY_PRESSED (+10)
 ????? B: KeyEvent.KEY_PRESSED (0)
 ????? C: KeyEvent.KEY_PRESSED (+20)

Which one gets the event first?? Does having a handler higher up the 
hierarchy trump priorities?

Providing an alternative solution that doesn't expose the user to a 
priority system that further complicates an already complicated system 
would be a big win.? If we can simply say to the user your 
filters/handlers will always go first that's a big win.

> - application event filters
>
> - application event handlers
>
> - event handlers set by the skin
>
> - ifUnconsumed-like handlers set by the skin
>
> - ifUnconsumed-like handlers set by the application
>
Let's say a KeyEvent.KEY_PRESSED is fired at a Control (focusOwner), 
then the order in which the event can be acted upon is:

- Scene hotkeys (Cut/Copy/Paste etc)
- Scene filters (set by user, KeyEvent.KEY_PRESSED first, then 
KeyEvent.ANY, then InputEvent.ANY, then Event.ANY)
- Parent?filters?(set by user, same order as above...)
- Control filters?(set by user)
- Control handlers (set by user)
- Parent handlers (set by user)
- Scene handlers (set by user)
- Scene checks unconsumed status, then processes the unconsumed handlers 
in order
-?Scene default button handling and mnemonic handling (if still 
unconsumed at this stage)

The order of the unconsumed handlers is the order they were registered 
in, which depends on where they were called from:

- ifUnconsumed called by Behavior filters set on Control
- ifUnconsumed called by Skin filters set on Control (possibly to 
forward these events to an inner component although they should only do 
so when ifUnconsumed calls them back)
- ifUnconsumed called by Behavior handlers set on Control
- ifUnconsumed called by Skin handlers set on Control

Note that Behavior always has the option to go first (and Skins should 
install their internal Behaviors early) by installing a filter.? 
Behavior's handlers also go first, but can be overridden by a Skin event 
filter.

Also note: the handlers may still get "mixed up" (user/system handlers), 
but as all Behavior/Skins will use `ifUnconsumed` and so go last in all 
cases, this has become irrelevant.

SO, neither Skin nor Behavior directly act on any incoming event, they 
only register their interest.? No Skin internal components are directly 
receiving events here.? Any event that is directly targeted at a Skin 
internal component can use regular means to handle events as there will 
not be a conflict with user handlers as those components are private to 
the Skin.

--John

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

From mhanl at openjdk.org  Tue Nov 12 21:16:33 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 12 Nov 2024 21:16:33 GMT
Subject: RFR: 8344067: TableCell indices can be outdated with the TableRow
 index
Message-ID: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>

This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.

What normally happens is:
- Index is changed: Cell update is requested when the row is empty (otherwise noop)
- Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`

Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
-> `oldIndex != newIndex && oldItem == newItem`
This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).

-> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 

The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).

Also made sure that the issues linked in the code do not regress:
- https://bugs.openjdk.org/browse/JDK-8095357
- https://bugs.openjdk.org/browse/JDK-8115269

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

Commit messages:
 - 8344067: TableCell indices can be outdated with the TableRow index

Changes: https://git.openjdk.org/jfx/pull/1635/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344067
  Stats: 169 lines in 5 files changed: 160 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1635.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1635/head:pull/1635

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

From angorya at openjdk.org  Tue Nov 12 23:37:14 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 12 Nov 2024 23:37:14 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
In-Reply-To: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
Message-ID: <gZF-PZrqXZIVh2ctFCIj4C3akuVAjXnyiKk26k7efQI=.e7ea9bf8-d877-49ed-9639-43aa5701b903@github.com>

On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
> 
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
> 
> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
> -> `oldIndex != newIndex && oldItem == newItem`
> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
> 
> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
> 
> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
> 
> ---
> 
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269

I'll review, thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1635#issuecomment-2471844726

From angorya at openjdk.org  Tue Nov 12 23:51:15 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 12 Nov 2024 23:51:15 GMT
Subject: Integrated: 8091673: Public focus traversal API for use in custom
 controls
In-Reply-To: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
References: <HVX-LJK-Pa6D14xNGNRT5FpemyWvQufV4JDCIyStEAI=.afdeca2b-e223-4965-aa81-a1dcc9e01c2f@github.com>
Message-ID: <WTyo2xxUjLJUq9QCFxtradMR87WKbufaSOi5al5bU2s=.2c159606-5eb0-4897-a253-813593373640@github.com>

On Wed, 6 Nov 2024 17:49:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Public focus traversal API for use in custom controls.
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
> 
> This is a lightweight change that only adds the public API for focus traversal, containing neither the public API for the traversal policy (#1555) nor with the changes for the traversal policy hidden (#1604).

This pull request has now been integrated.

Changeset: 688f7fa0
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/688f7fa0168143c9c73dd8f17cbe668f9d19f79c
Stats:     263 lines in 4 files changed: 262 ins; 0 del; 1 mod

8091673: Public focus traversal API for use in custom controls

Reviewed-by: kcr, mstrauss, jhendrikx

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

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

From angorya at openjdk.org  Wed Nov 13 00:22:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 00:22:07 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v40]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <h4OYT8tGuo6CRLIpk3fv_K9TM3lmn1jcNbyB5XE7RhA=.f7bcd8de-b741-4b9b-abe1-b12cdc8a5cd7@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  settings

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/05f533d0..8a52cf79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=39
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=38-39

  Stats: 410 lines in 7 files changed: 397 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Wed Nov 13 00:27:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 00:27:56 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v41]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <9SiGJm1d7W3o68ZP_WoQWhNNcsUZhctaSSkC2j5PAVI=.a5de2afe-96a6-47bc-911a-eb855749d23a@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - use focus traversal api
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - settings
 - comment
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - readme
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - review comments
 - input map
 - ... and 48 more: https://git.openjdk.org/jfx/compare/688f7fa0...7585ae30

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=40
  Stats: 40179 lines in 211 files changed: 40165 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From martin at martinfox.com  Wed Nov 13 00:31:31 2024
From: martin at martinfox.com (Martin Fox)
Date: Tue, 12 Nov 2024 16:31:31 -0800
Subject: Unconsumed event handlers
In-Reply-To: <e2ee1604-cb7e-4f80-9ac9-10efbcb61bf7@gmail.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
 <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com>
 <C7283E06-EE25-441C-A530-E9FD863E97CA@martinfox.com>
 <e2ee1604-cb7e-4f80-9ac9-10efbcb61bf7@gmail.com>
Message-ID: <26E36F40-BAD5-4266-9C5E-8F0AF23CD68B@martinfox.com>

John,

The issue occurs inside the event dispatchers. An event is passed into dispatchEvent which may return a separate event. What state is carried over from the incoming event to the outgoing event? If there are unconsumed event handlers attached to the incoming event are they also attached to the returned event?

There?s nothing in the EventDispatcher documentation that says that any state from the incoming event must be carried over to the outgoing event and currently the system doesn?t rely on any state being carried over. But as I understand it this PR will only work if the unconsumed event handlers are copied from the incoming event to the outgoing event.

If the dispatcher uses copyFor the state should be copied correctly. My guess is that the current JavaFX dispatchers will preserve this state but I haven?t take the time to review all the code (there?s a bunch of them).

Martin

> On Nov 12, 2024, at 11:06?AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> Hi Martin,
> 
> I'm still unsure how this exactly is supposed to go wrong.
> 
> Whenever you dispatch a new event, you should always follow-up and check if it was consumed after the dispatch finishes.  If it is, then you mark the triggering event also as consumed.  If this is done consistently everywhere, then the consumed flag should function as expected or not?
> 
> Code that does is simply wrong:
> 
>        e -> {
>              node.fireEvent(new KeyEvent(...));  // can't check if it was consumed!
>              // consume "e" or not?
>        }
> 
> The above is a bug, and needs to be fixed if it is present in FX.
> 
> So the way I see it, every time you fire a new event in response to another, it is your responsibility to ensure that you check if the new event was consumed, and if it was, to mark the initial event as consumed as well.  Following this everywhere should make the consumed flag work as expected.
> 
> What am I missing?
> 
> --John
> 
> On 12/11/2024 19:14, Martin Fox wrote:
>> (Here?s hoping this e-mail makes it out to the list. If this is an ongoing problem I might have to switch to using my gmail address.)
>> 
>> I?m writing up some notes to improve the documentation on event dispatch. There seems to be only one rule governing dispatchers and that is ?return null from dispatchEvent to end dispatch?. Beyond that anything goes.
>> 
>> From what I can tell this PR will work if the event passed to the handler is the original event or a copy created using copyFor() and the event returned from dispatchEvent is either the same one that was passed to the handlers or a copy created using copyFor(). These are all reasonable assumptions but there?s nothing in the API that enforces them. In the worst case an event dispatcher may receive an event, pass an entirely new event to one of its handlers, and then return yet another entirely new event from dispatchEvent.
>> 
>> (In the codebase there are three classes that implement EventDispatcher and thirteen that extend an existing EventDispatcher. My guess is that all of them behave reasonably and copy their events using copyFor but I haven?t actually cracked open the code to verify that.)
>> 
>> At this point I?ll resort to hand-waving and speculation. Perhaps this should be divorced from events and reframed in terms of the dispatch process. Instead of ?do this if this event is not consumed? it?s ?do this if the current dispatch ends without consuming an event?. The unconsumed event handlers would then be attached to the dispatch chain instead of the event. And that?s about as far as I?ve thought this through.
>> 
>> Martin
>> 
>>> On Nov 12, 2024, at 5:02?AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
>>> 
>>> I think `discardUnconsumedEventHandlers` is still a bit unpredictable, as it would depend on handler order.
>>> 
>>> The user handler would need to be called *after* Skin/Behavior handlers for it to be able to always discard any ifUnconsumed callbacks.  If the Skin is replaced, then it will re-register handlers and those will then be called last...
>>> 
>>> Of course, if we change Behaviors to do their work in filters, then we could get this to work properly.
>>> 
>>> --John
>>> 
>>> On 10/11/2024 08:12, Michael Strau? wrote:
>>>> In JavaFX, user code and skins share the same event system. Since
>>>> invocation order is fundamentally important for events, this leads to
>>>> a lot of problems when skins add event handlers to their controls.
>>>> Assume user code adds an event handler to a control, and _then_ sets a
>>>> skin that also adds an event handler for the same event. In this case,
>>>> the user-provided handler is invoked first. If the skin is set
>>>> _first_, the skin gets the first chance to handle the event (see also
>>>> https://bugs.openjdk.org/browse/JDK-8231245).
>>>> 
>>>> Prioritized event handlers might be a solution for this problem, but
>>>> they are quite difficult to get right. Instead, I think we can get
>>>> almost all of the benefits using a much simpler solution: unconsumed
>>>> event handlers.
>>>> 
>>>> We add a new method to the `Event` class:
>>>> 
>>>>     <E extends Event> void ifUnconsumed(EventHandler<E> handler)
>>>> 
>>>> When an event filter or an event handler receives an event, it calls
>>>> the `ifUnconsumed` method with another event handler. Then, after both
>>>> phases of event delivery have completed, the list of unconsumed event
>>>> handlers associated with the event is invoked in sequence. Once an
>>>> unconsumed event handler consumes the event, further propagation is
>>>> stopped.
>>>> 
>>>> Skins and their behaviors would then always use the unconsumed form of
>>>> event handlers:
>>>> 
>>>>     // inside a skin/behavior
>>>>     control.addEventHandler(
>>>>         KeyEvent.KEY_PRESSED,
>>>>         e -> e.ifUnconsumed(event -> {
>>>>             // act on the event
>>>>         }));
>>>> 
>>>> This allows user code to see an event during both the capture and
>>>> bubble phases without any inteference of the skin or behavior. If user
>>>> code doesn't consume the event, the skin or behavior gets to act on
>>>> it.
>>>> 
>>>> In addition to that, we add a second new method to the `Event` class:
>>>> 
>>>>     void discardUnconsumedEventHandlers()
>>>> 
>>>> Calling this method in an event handler allows user code to discard
>>>> any unconsumed event handlers that have been registered prior. Let's
>>>> consider an example where user code wants to prevent a control skin
>>>> from acting on the ENTER key event, but it also doesn't want to
>>>> consume the event. Adding an event handler to the control, and then
>>>> calling `discardUnconsumedEventHandlers()` inside of the event handler
>>>> achieves exactly that: it allows the ENTER key event to flow freely
>>>> through the control without interacting with it, since its unconsumed
>>>> event handlers will never be called.
>>>> 
>>>> Here is the PR for this proposal: https://github.com/openjdk/jfx/pull/1633


From jdv at openjdk.org  Wed Nov 13 04:42:54 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Nov 2024 04:42:54 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v11]
In-Reply-To: <EAe8zn76ie4KNu0LXHvyRO9AAyX-1iCkTaw3eNAbLT8=.af1eb031-5b35-4914-896a-94d2c1fb1431@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <vzY0ciJ9SVtNBwWsFkD-2D4jztX5mS1Q2wUuLjbEaKQ=.a6df9eaa-6800-4ccb-a105-9c45205f5b9f@github.com>
 <EAe8zn76ie4KNu0LXHvyRO9AAyX-1iCkTaw3eNAbLT8=.af1eb031-5b35-4914-896a-94d2c1fb1431@github.com>
Message-ID: <iINOIziUBWbgB1y-l7i2XZ4mo2mW7EfDil7DRUMFe98=.4d974f3f-d28b-47d3-a1cb-c155b9a45b77@github.com>

On Fri, 1 Nov 2024 16:59:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>     2. This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.

I think @mstr2 can use `/integrate delegate` Skara command as mentioned at https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate. So that @kevinrushforth can time this integration in future.

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2472359178

From mstrauss at openjdk.org  Wed Nov 13 06:21:03 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 13 Nov 2024 06:21:03 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v11]
In-Reply-To: <iINOIziUBWbgB1y-l7i2XZ4mo2mW7EfDil7DRUMFe98=.4d974f3f-d28b-47d3-a1cb-c155b9a45b77@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <vzY0ciJ9SVtNBwWsFkD-2D4jztX5mS1Q2wUuLjbEaKQ=.a6df9eaa-6800-4ccb-a105-9c45205f5b9f@github.com>
 <EAe8zn76ie4KNu0LXHvyRO9AAyX-1iCkTaw3eNAbLT8=.af1eb031-5b35-4914-896a-94d2c1fb1431@github.com>
 <iINOIziUBWbgB1y-l7i2XZ4mo2mW7EfDil7DRUMFe98=.4d974f3f-d28b-47d3-a1cb-c155b9a45b77@github.com>
Message-ID: <KBogx3-JUNHbhUJ8pPl_T3dFxVAGubcMKJwCIVkihqw=.0b01dffd-92a9-42d9-b23c-cf04c3d296f8@github.com>

On Wed, 13 Nov 2024 04:38:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> I'm just starting to look at this. The tests I ran look good so far, with two things to note:
>> 
>> 1. If `XImageLoaderFactory` fails to load, it with throw an `Error` that terminates the app. I left a comment and suggestion inline.
>> 2. This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.
>
>>     2. This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.
> 
> I think @mstr2 can use `/integrate delegate` Skara command as mentioned at https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate. So that @kevinrushforth can time this integration in future.

@jayathirthrao @hjohn Please review the latest changes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2472533895

From ajit.ghaisas at oracle.com  Wed Nov 13 06:59:48 2024
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 13 Nov 2024 06:59:48 +0000
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <82788822-6E84-4A0E-A7AD-9DDDFD1FCC69@oracle.com>

Vote: YES

Regards,
Ajit

> On 12 Nov 2024, at 9:52?PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.
> 
> Lukasz is a member of JavaFX team at Oracle, who has contributed 35 commits [2] to OpenJFX. Lukasz consistently participates in code reviews of various pull requests, especially in the graphics area.
> 
> Votes are due by Nov 26, 2024 at 17:00 UTC.
> 
> Only current OpenJFX Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4]. Nomination to a project Reviewer is described in [5].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.org/census#lkostyra
> 
> [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits
> 
> [3] https://openjdk.java.net/census#openjfx
> 
> [4] https://openjdk.java.net/bylaws#three-vote-consensus
> 
> [5] https://openjdk.java.net/projects#project-reviewer
> 


From jhendrikx at openjdk.org  Wed Nov 13 12:24:18 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 13 Nov 2024 12:24:18 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v19]
In-Reply-To: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
Message-ID: <6Kl9X-DUY32jFTMnaogysceknbzo_AeSNAHq5bBisEg=.8062a614-9766-4f65-beb8-6b1376bb0095@github.com>

On Sat, 9 Nov 2024 07:43:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into feature/ximageloader
>  - move automatically added imports
>  - rename test...javax -> test...java2d
>  - Merge branch 'master' into feature/ximageloader
>  - Merge branch 'master' into feature/ximageloader
>  - rename iio.javax -> iio.java2d
>  - revert doc change
>  - Merge branch 'master' into feature/ximageloader
>  - validate max image width/height
>  - catch NoClassDefFoundError
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - ... and 23 more: https://git.openjdk.org/jfx/compare/d0011b21...d8d2a9c1

This looks good, I will re-approve if you decide to apply my suggestion for the exception messages.

modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 216:

> 214:     public static void validateMaxDimensions(double width, double height, double scaleFactor) {
> 215:         if (width * scaleFactor > Integer.MAX_VALUE) {
> 216:             throw new IllegalArgumentException("Image width exceeds maximum value");

You may want to include the values used to reach this conclusion here and with the other 2 exceptions; if these exceptions ever come up, that's the first thing a developer will likely want to know (which may be you if this is posted in an issue).

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2432927798
PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1840156132

From kcr at openjdk.org  Wed Nov 13 12:32:43 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 12:32:43 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v19]
In-Reply-To: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
Message-ID: <lHDTRe0XWcmsB1p199bSplVhPiXW7rkOydFyhvwP8CU=.7ccb1161-aa16-4144-b078-fb02909a75c8@github.com>

On Sat, 9 Nov 2024 07:43:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into feature/ximageloader
>  - move automatically added imports
>  - rename test...javax -> test...java2d
>  - Merge branch 'master' into feature/ximageloader
>  - Merge branch 'master' into feature/ximageloader
>  - rename iio.javax -> iio.java2d
>  - revert doc change
>  - Merge branch 'master' into feature/ximageloader
>  - validate max image width/height
>  - catch NoClassDefFoundError
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - ... and 23 more: https://git.openjdk.org/jfx/compare/d0011b21...d8d2a9c1

All looks good. I'll reapprove if you decide to make the changes suggested by John.

I'll integrate it later this morning (Pacific time) if all is settled.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2432962879

From kcr at openjdk.org  Wed Nov 13 12:32:44 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 12:32:44 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v11]
In-Reply-To: <KBogx3-JUNHbhUJ8pPl_T3dFxVAGubcMKJwCIVkihqw=.0b01dffd-92a9-42d9-b23c-cf04c3d296f8@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <vzY0ciJ9SVtNBwWsFkD-2D4jztX5mS1Q2wUuLjbEaKQ=.a6df9eaa-6800-4ccb-a105-9c45205f5b9f@github.com>
 <EAe8zn76ie4KNu0LXHvyRO9AAyX-1iCkTaw3eNAbLT8=.af1eb031-5b35-4914-896a-94d2c1fb1431@github.com>
 <iINOIziUBWbgB1y-l7i2XZ4mo2mW7EfDil7DRUMFe98=.4d974f3f-d28b-47d3-a1cb-c155b9a45b77@github.com>
 <KBogx3-JUNHbhUJ8pPl_T3dFxVAGubcMKJwCIVkihqw=.0b01dffd-92a9-42d9-b23c-cf04c3d296f8@github.com>
Message-ID: <o9mfzX2i4Yujuo5W_OfffySDfU7rXIN-mmuffavXYrs=.56b06bc7-4997-437a-bf2d-f0a2800886fb@github.com>

On Wed, 13 Nov 2024 06:17:18 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>>     2. This patch causes a failure in one of our closed white-box tests, which depends on internal API that has changed. It will be easy for us to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.
>> 
>> I think @mstr2 can use `/integrate delegate` Skara command as mentioned at https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate. So that @kevinrushforth can time this integration in future.
>
> @jayathirthrao @hjohn Please review the latest changes.

> I think @mstr2 can use /integrate delegate Skara command

Thanks, Jay, I was going to suggest the same as an option for this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2473471356

From kcr at openjdk.org  Wed Nov 13 13:37:07 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:37:07 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v2]
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <8ab1l9D8v0LiPCSUUXLhd_U1ByX93ANxPXD0iBIMZaU=.38438e6d-2177-43d3-ac6e-bb89122bbb12@github.com>

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision:

 - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
 - Additional cleanup of unused fields, imports, and comments related to permissions
 - Review comments: remove unused field, methods in FXMLLoader

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1631/files
  - new: https://git.openjdk.org/jfx/pull/1631/files/72cdb737..5efde51e

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

  Stats: 48 lines in 12 files changed: 1 ins; 35 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1631.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1631/head:pull/1631

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

From kcr at openjdk.org  Wed Nov 13 13:37:07 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:37:07 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v2]
In-Reply-To: <8ab1l9D8v0LiPCSUUXLhd_U1ByX93ANxPXD0iBIMZaU=.38438e6d-2177-43d3-ac6e-bb89122bbb12@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <8ab1l9D8v0LiPCSUUXLhd_U1ByX93ANxPXD0iBIMZaU=.38438e6d-2177-43d3-ac6e-bb89122bbb12@github.com>
Message-ID: <FSMi445X5sayVMxK6cxRtrdgXUCIXICCV6g1AvUxy5g=.b0d6f329-4295-4557-bfb2-2d435d7b2ac0@github.com>

On Wed, 13 Nov 2024 13:33:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
>> 
>> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
>> 
>> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
>> 
>> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).
>
> Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
>  - Additional cleanup of unused fields, imports, and comments related to permissions
>  - Review comments: remove unused field, methods in FXMLLoader

In addition to the suggested changes, I did one more pass looking for unused fields, imports, and comments related to permissions.

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

PR Review: https://git.openjdk.org/jfx/pull/1631#pullrequestreview-2429805137

From kcr at openjdk.org  Wed Nov 13 13:37:08 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:37:08 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v2]
In-Reply-To: <a0s8HxmODxpxMYvDxPAwzHv2a6wHJzlwhqjJiy2QAG4=.4349c475-67f1-4d40-af2a-e33d54ef7f23@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <a0s8HxmODxpxMYvDxPAwzHv2a6wHJzlwhqjJiy2QAG4=.4349c475-67f1-4d40-af2a-e33d54ef7f23@github.com>
Message-ID: <fmyPt-vSM4TpRUl6EOCM1shZ4eY1NSxH_lAdUFk_w9Q=.1bd7d44d-55ef-432b-bb10-eafd6b1868f1@github.com>

On Fri, 8 Nov 2024 22:06:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
>>  - Additional cleanup of unused fields, imports, and comments related to permissions
>>  - Review comments: remove unused field, methods in FXMLLoader
>
> modules/javafx.base/src/main/java/com/sun/javafx/reflect/ReflectUtil.java line 82:
> 
>> 80:      */
>> 81:     public static void checkPackageAccess(String name) {
>> 82:         @SuppressWarnings("removal")
> 
> will there be a ticket for further cleanup of unused/unnecessary methods?

Since this class is derived from the similar JDK class, I want to be informed by what they do after the SM removal JEP is integrated. I filed [JDK-8344117](https://bugs.openjdk.org/browse/JDK-8344117) as a Task to track this, which may or may not lead to a follow-up bug.

> modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontFactory.java line 55:
> 
>> 53:     public String[] getFontFullNames(String family);
>> 54: 
>> 55:     // TODO: SM removal: condider removing in a follow-up issue
> 
> maybe it's better to create a ticket and reference that instead?

Good idea. I'll do that.

> modules/javafx.graphics/src/main/java/javafx/scene/input/Dragboard.java line 52:
> 
>> 50:     @Override
>> 51:     Object getContentImpl(DataFormat dataFormat) {
>> 52:         if (dataAccessRestricted) {
> 
> this method can be deleted here

What method? Not `getContentImpl`, since that's the primary method to retrieve the content and is still used and needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1838229973
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1838230883
PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1838231353

From kcr at openjdk.org  Wed Nov 13 13:37:08 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:37:08 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v2]
In-Reply-To: <gLWXnxErOSslkS-ha5AY-SSMBwWMQgbCBASrKXOVF1Q=.4ba2d4a2-7651-4732-97f3-f9b9d4bb48b4@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <gLWXnxErOSslkS-ha5AY-SSMBwWMQgbCBASrKXOVF1Q=.4ba2d4a2-7651-4732-97f3-f9b9d4bb48b4@github.com>
Message-ID: <wlW7w3wDg-7u11tU-ag1COvIDCrN6BaWhkVdWpB1ja8=.46e226fd-b8d3-4074-9ada-10ea41f8f46b@github.com>

On Mon, 11 Nov 2024 08:12:08 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
>>  - Additional cleanup of unused fields, imports, and comments related to permissions
>>  - Review comments: remove unused field, methods in FXMLLoader
>
> modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 107:
> 
>> 105: 
>> 106:     // Indicates permission to get the ClassLoader
>> 107:     private static final RuntimePermission GET_CLASSLOADER_PERMISSION =
> 
> I think this is unused and can be removed too

Thanks. I missed that. Related to this, the `needsClassLoaderPermissionCheck` method is similarly unused, so I'll remove that method as well. Also related, the private `checkClassLoaderPermission` method is now a no-op, and is only used in two places in this file, so I'll remove the method and the two calls.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1838230513

From kcr at openjdk.org  Wed Nov 13 13:44:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:44:39 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v3]
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <ooXRQJFqwLxX1sQ_kWQFDbmUbvFwwGHg-3xIao7WeD0=.1e9e3bc2-0bd1-4fc2-bb04-f7a9c16d7c54@github.com>

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Restore mistakenly removed comment.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1631/files
  - new: https://git.openjdk.org/jfx/pull/1631/files/5efde51e..9dfd64bc

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

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

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

From kcr at openjdk.org  Wed Nov 13 13:44:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:44:41 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v3]
In-Reply-To: <fmyPt-vSM4TpRUl6EOCM1shZ4eY1NSxH_lAdUFk_w9Q=.1bd7d44d-55ef-432b-bb10-eafd6b1868f1@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <a0s8HxmODxpxMYvDxPAwzHv2a6wHJzlwhqjJiy2QAG4=.4349c475-67f1-4d40-af2a-e33d54ef7f23@github.com>
 <fmyPt-vSM4TpRUl6EOCM1shZ4eY1NSxH_lAdUFk_w9Q=.1bd7d44d-55ef-432b-bb10-eafd6b1868f1@github.com>
Message-ID: <Qe24msZk7Kotsca4iLtcg-g_RNaLL7BuT_tgX8xd5rs=.2ac86983-dbc9-4595-a53b-10ad23074625@github.com>

On Tue, 12 Nov 2024 14:45:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/input/Dragboard.java line 52:
>> 
>>> 50:     @Override
>>> 51:     Object getContentImpl(DataFormat dataFormat) {
>>> 52:         if (dataAccessRestricted) {
>> 
>> this method can be deleted here
>
> What method? Not `getContentImpl`, since that's the primary method to retrieve the content and is still used and needed.

Oh, I see what you mean now. You mean that `Dragboard` no longer needs to override this method, since all it does now is call `super`. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1840301009

From kcr at openjdk.org  Wed Nov 13 13:58:28 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 13:58:28 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v4]
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <P_lMfMECbsAM6qRdNFyFjs1VFJ7hchFCpnd4F-zP-R8=.8d3bdd2e-ae44-4463-b5ff-daaf84747878@github.com>

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant override of Dragboard::getContentImpl

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1631/files
  - new: https://git.openjdk.org/jfx/pull/1631/files/9dfd64bc..0aac910a

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

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

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

From angorya at openjdk.org  Wed Nov 13 15:49:49 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 15:49:49 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v4]
In-Reply-To: <P_lMfMECbsAM6qRdNFyFjs1VFJ7hchFCpnd4F-zP-R8=.8d3bdd2e-ae44-4463-b5ff-daaf84747878@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <P_lMfMECbsAM6qRdNFyFjs1VFJ7hchFCpnd4F-zP-R8=.8d3bdd2e-ae44-4463-b5ff-daaf84747878@github.com>
Message-ID: <ZF7Cetij8Et3I3eIFWDK3Lz1-k7nuv4C1MqGNCHLk5o=.36443461-e280-4e89-a72e-4eb71c067b81@github.com>

On Wed, 13 Nov 2024 13:58:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
>> 
>> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
>> 
>> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
>> 
>> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant override of Dragboard::getContentImpl

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 596:

> 594:     }
> 595: 
> 596:     // TODO: JDK-8344111: Consider removing this obsolete method

what method?  there is no method, only the field L597

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1631#discussion_r1840648086

From kcr at openjdk.org  Wed Nov 13 15:53:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 15:53:49 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v5]
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <b55LlTUJPGR9C2da76R2CdWmQx4mSFoa5LQxpRj_e5Y=.3f8b4415-3be1-43e5-8741-4216375018c7@github.com>

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  fix copy/paste error in comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1631/files
  - new: https://git.openjdk.org/jfx/pull/1631/files/0aac910a..159e204e

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

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

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

From angorya at openjdk.org  Wed Nov 13 15:59:24 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 15:59:24 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v5]
In-Reply-To: <b55LlTUJPGR9C2da76R2CdWmQx4mSFoa5LQxpRj_e5Y=.3f8b4415-3be1-43e5-8741-4216375018c7@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <b55LlTUJPGR9C2da76R2CdWmQx4mSFoa5LQxpRj_e5Y=.3f8b4415-3be1-43e5-8741-4216375018c7@github.com>
Message-ID: <JHKD2DTeWUQA1csZ27E4o0iIlg7vflLEMDDWFLrDwbw=.e6e78129-e661-44ed-ab25-c1078f17f3ba@github.com>

On Wed, 13 Nov 2024 15:53:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
>> 
>> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
>> 
>> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
>> 
>> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copy/paste error in comment

looks good

also checked for unused imports -
there are 540 unused import warnings, some in the generated code (can't be helped), some newly introduced by the junit5 conversion, and none in this PR.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1631#pullrequestreview-2433682201

From jdv at openjdk.org  Wed Nov 13 17:03:27 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Nov 2024 17:03:27 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v19]
In-Reply-To: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
Message-ID: <YFNi9Md9Q8FXJHsRMsUwN1donbOrUh8w1jkP_zsJi5g=.93fb70f4-548c-4b53-bad4-184c7bb4a713@github.com>

On Sat, 9 Nov 2024 07:43:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into feature/ximageloader
>  - move automatically added imports
>  - rename test...javax -> test...java2d
>  - Merge branch 'master' into feature/ximageloader
>  - Merge branch 'master' into feature/ximageloader
>  - rename iio.javax -> iio.java2d
>  - revert doc change
>  - Merge branch 'master' into feature/ximageloader
>  - validate max image width/height
>  - catch NoClassDefFoundError
>    
>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>  - ... and 23 more: https://git.openjdk.org/jfx/compare/d0011b21...d8d2a9c1

Marked as reviewed by jdv (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2433879175

From angorya at openjdk.org  Wed Nov 13 18:10:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 18:10:38 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
In-Reply-To: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
Message-ID: <6GfAeWON_T4jJBAXkhexTsWrbME0UOpTRAg6pTnWMsc=.58babcce-c367-406f-b38f-7c4b44396098@github.com>

On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
> 
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
> 
> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
> -> `oldIndex != newIndex && oldItem == newItem`
> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
> 
> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
> 
> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
> 
> ---
> 
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269

The bug is present in TableView and TreeTableView, but not TreeView - is this correct?

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

PR Comment: https://git.openjdk.org/jfx/pull/1635#issuecomment-2474373968

From angorya at openjdk.org  Wed Nov 13 18:22:44 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 18:22:44 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
In-Reply-To: <L1C6Bf1L0MXJvxGQYBu7rNiQwgVc3zdWCs1HtkX3lpo=.34478638-a6cb-46d6-bfb3-9692f395cbd1@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
 <L1C6Bf1L0MXJvxGQYBu7rNiQwgVc3zdWCs1HtkX3lpo=.34478638-a6cb-46d6-bfb3-9692f395cbd1@github.com>
Message-ID: <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com>

On Wed, 13 Nov 2024 18:10:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
>> 
>> What normally happens is:
>> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
>> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
>> 
>> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
>> -> `oldIndex != newIndex && oldItem == newItem`
>> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
>> 
>> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
>> 
>> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
>> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
>> 
>> ---
>> 
>> Also made sure that the issues linked in the code and ticket do not regress:
>> - https://bugs.openjdk.org/browse/JDK-8095357
>> - https://bugs.openjdk.org/browse/JDK-8115269
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 222:
> 
>> 220:         row.updateIndex(0);
>> 221: 
>> 222:         List<TableCell<String, String>> cells = row.getChildrenUnmodifiable().stream().
> 
> minor suggestion: maybe reformat to keep one statement per line
> 
> 
> row.getChildrenUnmodifiable().stream().
>    filter(TableCell.class::isInstance).
>    map(e -> (TableCell<String, String>) e).
>    toList();

(here and elsewhere)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1840949564

From angorya at openjdk.org  Wed Nov 13 18:22:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 18:22:43 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
In-Reply-To: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
Message-ID: <L1C6Bf1L0MXJvxGQYBu7rNiQwgVc3zdWCs1HtkX3lpo=.34478638-a6cb-46d6-bfb3-9692f395cbd1@github.com>

On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
> 
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
> 
> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
> -> `oldIndex != newIndex && oldItem == newItem`
> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
> 
> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
> 
> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
> 
> ---
> 
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269

tested with SCCE found in the ticket on macOS M1 14.7, also some limited testing with the monkey tester, no issues found.

looks good; left some very minor formatting suggestions - will re-approve should you decide to fix.

thanks for writing the tests!

1 reviewer should be enough.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 222:

> 220:         row.updateIndex(0);
> 221: 
> 222:         List<TableCell<String, String>> cells = row.getChildrenUnmodifiable().stream().

minor suggestion: maybe reformat to keep one statement per line


row.getChildrenUnmodifiable().stream().
   filter(TableCell.class::isInstance).
   map(e -> (TableCell<String, String>) e).
   toList();

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 6335:

> 6333:     @Test
> 6334:     void testReSetItemsWithSameItemShouldUpdateCellIndices() {
> 6335:         table.setFixedCellSize(24);

fixed size is not essential to the test, right?  I've tested with the SCCE in the ticket, it has no effect.

it's probably ok to leave it here though.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1635#pullrequestreview-2434075916
PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1840949234
PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1840951836

From mstrauss at openjdk.org  Wed Nov 13 18:33:27 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 13 Nov 2024 18:33:27 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

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

  include image size in exception message

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1593/files
  - new: https://git.openjdk.org/jfx/pull/1593/files/d8d2a9c1..85a39fb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1593&range=18-19

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

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

From mstrauss at openjdk.org  Wed Nov 13 18:39:30 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 13 Nov 2024 18:39:30 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v19]
In-Reply-To: <6Kl9X-DUY32jFTMnaogysceknbzo_AeSNAHq5bBisEg=.8062a614-9766-4f65-beb8-6b1376bb0095@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com>
 <6Kl9X-DUY32jFTMnaogysceknbzo_AeSNAHq5bBisEg=.8062a614-9766-4f65-beb8-6b1376bb0095@github.com>
Message-ID: <SdI-nLCexpSDqRIHXnL9qvyZxWw0JFi8XyGfnvtsfKc=.a49c596a-ecc9-4978-bad7-909224c74444@github.com>

On Wed, 13 Nov 2024 12:15:20 GMT, John Hendrikx <jhendrikx 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 33 commits:
>> 
>>  - Merge branch 'master' into feature/ximageloader
>>  - move automatically added imports
>>  - rename test...javax -> test...java2d
>>  - Merge branch 'master' into feature/ximageloader
>>  - Merge branch 'master' into feature/ximageloader
>>  - rename iio.javax -> iio.java2d
>>  - revert doc change
>>  - Merge branch 'master' into feature/ximageloader
>>  - validate max image width/height
>>  - catch NoClassDefFoundError
>>    
>>    Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>
>>  - ... and 23 more: https://git.openjdk.org/jfx/compare/d0011b21...d8d2a9c1
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/common/ImageTools.java line 216:
> 
>> 214:     public static void validateMaxDimensions(double width, double height, double scaleFactor) {
>> 215:         if (width * scaleFactor > Integer.MAX_VALUE) {
>> 216:             throw new IllegalArgumentException("Image width exceeds maximum value");
> 
> You may want to include the values used to reach this conclusion here and with the other 2 exceptions; if these exceptions ever come up, that's the first thing a developer will likely want to know (which may be you if this is posted in an issue).

Changed as suggested.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1593#discussion_r1840981078

From kcr at openjdk.org  Wed Nov 13 18:53:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 18:53:37 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
Message-ID: <SN_GEpZmwodjRWkExx9bE-T95TKziawkbgWLAXCPMaU=.dc6bb70e-535f-4329-8572-f478486e622d@github.com>

On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include image size in exception message

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2434157191

From andy.goryachev at oracle.com  Wed Nov 13 19:33:29 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 13 Nov 2024 19:33:29 +0000
Subject: Focus delegation API
In-Reply-To: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
Message-ID: <BYAPR10MB3013A4B3062D686CDE6C147EE55A2@BYAPR10MB3013.namprd10.prod.outlook.com>

I feel this is going in a wrong direction: the root cause of the issues we are observing, in my opinion, is that the top-level Control is fighting for control with the inner control, and the inner control's behaves as if it is a top-level control.

What should happen instead is to provide a way for the top-level Control to disable those aspects of the inner control behavior (event handlers, key bindings) that are not needed anymore, and replace them with the new logic.
Continuing the Spinner example, it is ok for the TextField (Spinner.editor) to receive events, but the handling of certain key combinations should be disabled and instead bubbled up to the Spinner behavior.

I propose to use the InputMap https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md for this purpose.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, November 8, 2024 at 17:35
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Focus delegation API
Hi everyone,

here is a proposal to finally solve the focus delegation problem that
has recently been discussed in the "Prioritized event handlers"
thread.

Proposal: https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29
Draft PR: https://github.com/openjdk/jfx/pull/1632
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241113/ab370df2/attachment.htm>

From jhendrikx at openjdk.org  Wed Nov 13 19:31:56 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 13 Nov 2024 19:31:56 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
Message-ID: <jMFNekJZ8AKqgWl76KKT6PrpTlaDa5aWebzzQVIlGpM=.7bf08211-dc95-40ef-867f-2f74d08fda35@github.com>

On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include image size in exception message

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1593#pullrequestreview-2434231944

From mhanl at openjdk.org  Wed Nov 13 19:54:32 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 13 Nov 2024 19:54:32 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
In-Reply-To: <6GfAeWON_T4jJBAXkhexTsWrbME0UOpTRAg6pTnWMsc=.58babcce-c367-406f-b38f-7c4b44396098@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
 <6GfAeWON_T4jJBAXkhexTsWrbME0UOpTRAg6pTnWMsc=.58babcce-c367-406f-b38f-7c4b44396098@github.com>
Message-ID: <toJD9Mbe1r0N3xPgY7p08dxEEyGnq83NU8fkrHZ5qk8=.725bd432-35a2-4f9c-8073-7a835571f813@github.com>

On Wed, 13 Nov 2024 18:07:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The bug is present in TableView and TreeTableView, but not TreeView - is this correct?

Yes since `ListView` and `TreeView` do not need to do any synchronization when their index or item changed. But I did not test them.

> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 6335:
> 
>> 6333:     @Test
>> 6334:     void testReSetItemsWithSameItemShouldUpdateCellIndices() {
>> 6335:         table.setFixedCellSize(24);
> 
> fixed size is not essential to the test, right?  I've tested with the SCCE in the ticket, it has no effect.
> 
> it's probably ok to leave it here though.

Ah yes, I used it initially to better predict the `ScrollBar`, but is indeed not necessary.

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

PR Comment: https://git.openjdk.org/jfx/pull/1635#issuecomment-2474617765
PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1841075029

From mhanl at openjdk.org  Wed Nov 13 20:02:01 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 13 Nov 2024 20:02:01 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
 [v2]
In-Reply-To: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
Message-ID: <ElIjiMGRGYkY064aJI6u2OSGhPVpkvhIYlkaFLXvbCw=.3515f437-721d-4ac4-bb32-784546121812@github.com>

> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
> 
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
> 
> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
> -> `oldIndex != newIndex && oldItem == newItem`
> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
> 
> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
> 
> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
> 
> ---
> 
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  8344067: Format streams

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1635/files
  - new: https://git.openjdk.org/jfx/pull/1635/files/54f7445d..aa782c23

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

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

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

From mhanl at openjdk.org  Wed Nov 13 20:02:02 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 13 Nov 2024 20:02:02 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
 [v2]
In-Reply-To: <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
 <L1C6Bf1L0MXJvxGQYBu7rNiQwgVc3zdWCs1HtkX3lpo=.34478638-a6cb-46d6-bfb3-9692f395cbd1@github.com>
 <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com>
Message-ID: <MJR2muiG_hZ-mKYh_dJypCFmoc1qjSrvDURnG5XIv6A=.49b5e88b-9575-4a05-aade-8cbf0bb66e6c@github.com>

On Wed, 13 Nov 2024 18:10:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 222:
>> 
>>> 220:         row.updateIndex(0);
>>> 221: 
>>> 222:         List<TableCell<String, String>> cells = row.getChildrenUnmodifiable().stream().
>> 
>> minor suggestion: maybe reformat to keep one statement per line
>> 
>> 
>> row.getChildrenUnmodifiable().stream().
>>    filter(TableCell.class::isInstance).
>>    map(e -> (TableCell<String, String>) e).
>>    toList();
>
> (here and elsewhere)

I usually keep it this way as it is still readable and less space. But changed the formatting so that the statement with the dot `.filter` is in the new line. This is as far as I know what most people do.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1841083038

From andy.goryachev at oracle.com  Wed Nov 13 20:08:35 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 13 Nov 2024 20:08:35 +0000
Subject: Unconsumed event handlers
In-Reply-To: <84eda7bc-1027-465e-80df-a28d4bf69256@gmail.com>
References: <CAJEpuXTYxT+mEMziW0CwD=rLj5g6qXrTCi58AfO11oq4115+Uw@mail.gmail.com>
 <BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.namprd10.prod.outlook.com>
 <84eda7bc-1027-465e-80df-a28d4bf69256@gmail.com>
Message-ID: <BYAPR10MB3013AD5B51693548F6EB6FD3E55A2@BYAPR10MB3013.namprd10.prod.outlook.com>

> I think if we can find a solution that doesn't require priorities that it should by far be preferred

That was exactly my rationale for implementing the prioritization at the Controls level with the InputMap.

But we may be jumping ahead in the discussion.  Remember I asked the question of whether the "priority inversion" problem we see with Controls also appears outside of controls?  Because if it does, if the current two-level priority scheme with event filter / event handler duo is insufficient, then we need Michael's idea of explicit prioritization of the event handlers.

Getting into the Controls, there is a need for more priority levels.  I tried to explain that in the InputMap proposal earlier, but basically it's


Highest
Application
InputMap.addEventHandler()
Event handlers set by the application
Application
InputMap.registerKey()
Key mappings set by the application
Skin
SkinInputMap.registerKey()
Key mappings set by the skin
Skin
SkinInputMap.addEventHandler()
Event handlers set by the skin
Skin
SkinInputMap.addEventHandlerLast()
Event handlers set by the skin
Lowest
Application
InputMap.addEventHandlerLast()
Event handlers set by the application

There might be more, if we want to give the application a chance to add a handler before SkinInputMap.addEventHandlerLast(), but it is not important at the moment, the important thing is that we'll need some number of priority levels to reliably control the event handling between the application and the skins.

I feel we need to come to a conclusion on the EH prioritization before we can talk about the input maps and the focus.

I must also say I don't care where we solve the priority issue - at the event dispatch level, or at the input map level.  If we decide to do it globally, then the input map will plug into the global mechanism, or we can resolve the issues for the controls specifically via the input map, but many people seem to dislike this idea on a symmetry-breaking grounds.

What do you think?

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Tuesday, November 12, 2024 at 12:18
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Unconsumed event handlers


On 12/11/2024 18:31, Andy Goryachev wrote:
I am not sure this is the best solution, since it does not solve the problem of multiple actors adding their event handlers.  I do like the idea of prioritized event handlers, because it solves the problem *reliably*.

I think there is no way around it - we need different priorities.  It may be a set or may be a wide range of integers (for the maximum flexibility), but the main idea is that, at least in controls, we have a situation where there are at least these priorities:

I think if we can find a solution that doesn't require priorities that it should by far be preferred.  You have to think more from a user perspective.  They have a Button, and they add an Event Handler to do something with the SPACE key.  They run their code, and they find SPACE just disappears and never arrives at their handler.  However, if they add the handler in the Constructor of a Button subclass, or before the Skin is applied, then the handler does work.  There should not be a difference for the user, because the Event Handler system does not stipulate that there are internal handlers that are sharing this infrastructure; for the user the system looks like it is available solely for their use.

Let's say you now add priorities.  What possible reason could a user have for adding an event handler (for SPACE key) that wouldn't work (too low priority) or doesn't work reliably (equal priority)?  In other words, the only relevant priority for users is the one that will make their handler work, which more often than not will be MAX.

Now let's say we have a Node, and we add several handlers:

     Event.ANY (+10)
     KeyEvent.KEY_ANY (+20)
     KeyEvent.KEY_PRESSED (0)

What order are they going to be called?  Without priorities that would be KEY_PRESSED, KEY_ANY, ANY

Now let's have a hierarchy of Nodes, A -> B -> C -- I add the following handlers:

      A: KeyEvent.KEY_PRESSED (+10)
      B: KeyEvent.KEY_PRESSED (0)
      C: KeyEvent.KEY_PRESSED (+20)

Which one gets the event first?  Does having a handler higher up the hierarchy trump priorities?

Providing an alternative solution that doesn't expose the user to a priority system that further complicates an already complicated system would be a big win.  If we can simply say to the user your filters/handlers will always go first that's a big win.

- application event filters
- application event handlers
- event handlers set by the skin
- ifUnconsumed-like handlers set by the skin
- ifUnconsumed-like handlers set by the application


Let's say a KeyEvent.KEY_PRESSED is fired at a Control (focusOwner), then the order in which the event can be acted upon is:

- Scene hotkeys (Cut/Copy/Paste etc)
- Scene filters (set by user, KeyEvent.KEY_PRESSED first, then KeyEvent.ANY, then InputEvent.ANY, then Event.ANY)
- Parent filters (set by user, same order as above...)
- Control filters (set by user)
- Control handlers (set by user)
- Parent handlers (set by user)
- Scene handlers (set by user)
- Scene checks unconsumed status, then processes the unconsumed handlers in order
- Scene default button handling and mnemonic handling (if still unconsumed at this stage)

The order of the unconsumed handlers is the order they were registered in, which depends on where they were called from:

- ifUnconsumed called by Behavior filters set on Control
- ifUnconsumed called by Skin filters set on Control (possibly to forward these events to an inner component although they should only do so when ifUnconsumed calls them back)
- ifUnconsumed called by Behavior handlers set on Control
- ifUnconsumed called by Skin handlers set on Control

Note that Behavior always has the option to go first (and Skins should install their internal Behaviors early) by installing a filter.  Behavior's handlers also go first, but can be overridden by a Skin event filter.

Also note: the handlers may still get "mixed up" (user/system handlers), but as all Behavior/Skins will use `ifUnconsumed` and so go last in all cases, this has become irrelevant.

SO, neither Skin nor Behavior directly act on any incoming event, they only register their interest.  No Skin internal components are directly receiving events here.  Any event that is directly targeted at a Skin internal component can use regular means to handle events as there will not be a conflict with user handlers as those components are private to the Skin.

--John


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

From andy.goryachev at oracle.com  Wed Nov 13 20:10:42 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 13 Nov 2024 20:10:42 +0000
Subject: Prioritized event handlers
In-Reply-To: <DM5PR1001MB21720B81E7695223DB8601BFE5A1A@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <DM5PR1001MB21720B81E7695223DB8601BFE5A1A@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <BYAPR10MB3013A68D7011C923FF8985F0E55A2@BYAPR10MB3013.namprd10.prod.outlook.com>

Michael:

Did you ever respond to this message (30 October 2023, pretty fresh)?

Something weird is going on - I can't find this message in the archive, but several people did respond to it, but not you (or maybe your response went to the same /dev/null as my original post).

-andy



From: Andy Goryachev <andy.goryachev at oracle.com>
Date: Monday, October 30, 2023 at 12:53
To: Michael Strau? <michaelstrau2 at gmail.com>, openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Dear Michael:

Thank you, this is very helpful.

Questions/Comments:

1. Does this proposal changes the way events are dispatched with respect to priority?  In other words, does it first go through the list of all handlers registred on the leaf Node (high priority first, then lower, then lowest), then bubble up?  Or do they propagate upwards looking for high priority handlers first, then the process restarts for lower priorities, as I saw in some previous emails?  (I could be mistaken)

2. Do you propose to abort event dispatching immediately after the event is consumed?  This probably should be mentioned earlier in the Motivation (the problem statement) section.

3. I wonder if three priority levels are sufficient.  Let me explain.  We have two possible actors who can register an event listener: the application code and the FX (or, rather more specifically, the skin and its behavior, whatever that might be).

Application code might want to add handlers at three possible priorities:


  *   App handler must always be called before any fx handler
  *   App hander does not care
  *   App handler must always be called after any fx handlers

For fx/skin handlers we might have fewer levels:


  *   Skin handler does not care
  *   Skin handler must be called after all other skin handlers

This situation maps to 5 priorities and 4 effective levels (or 5).

We should also mention the fact that when any actor adds two or more handlers for the same event with the same priority, they get invoked in the order added.

Would you agree, or am I missing some critical aspect of the proposed solution?

Thank you
-andy





From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1

Comments are welcome.


On Fri, Oct 27, 2023 at 8:21?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241113/91509deb/attachment-0001.htm>

From angorya at openjdk.org  Wed Nov 13 20:19:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 20:19:35 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
 [v2]
In-Reply-To: <ElIjiMGRGYkY064aJI6u2OSGhPVpkvhIYlkaFLXvbCw=.3515f437-721d-4ac4-bb32-784546121812@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
 <ElIjiMGRGYkY064aJI6u2OSGhPVpkvhIYlkaFLXvbCw=.3515f437-721d-4ac4-bb32-784546121812@github.com>
Message-ID: <NgzsebdaGfQe3jFqSI2rt2Mue42N9wQtonETjyCv0nY=.1a93fcae-2ec7-4843-9b5d-eda9bf992d7d@github.com>

On Wed, 13 Nov 2024 20:02:01 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
>> 
>> What normally happens is:
>> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
>> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
>> 
>> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
>> -> `oldIndex != newIndex && oldItem == newItem`
>> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
>> 
>> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
>> 
>> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
>> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
>> 
>> ---
>> 
>> Also made sure that the issues linked in the code and ticket do not regress:
>> - https://bugs.openjdk.org/browse/JDK-8095357
>> - https://bugs.openjdk.org/browse/JDK-8115269
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344067: Format streams

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1635#pullrequestreview-2434323446

From angorya at openjdk.org  Wed Nov 13 20:19:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 20:19:36 GMT
Subject: RFR: 8344067: TableCell indices may not match the TableRow index
 [v2]
In-Reply-To: <MJR2muiG_hZ-mKYh_dJypCFmoc1qjSrvDURnG5XIv6A=.49b5e88b-9575-4a05-aade-8cbf0bb66e6c@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
 <L1C6Bf1L0MXJvxGQYBu7rNiQwgVc3zdWCs1HtkX3lpo=.34478638-a6cb-46d6-bfb3-9692f395cbd1@github.com>
 <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com>
 <MJR2muiG_hZ-mKYh_dJypCFmoc1qjSrvDURnG5XIv6A=.49b5e88b-9575-4a05-aade-8cbf0bb66e6c@github.com>
Message-ID: <SRZGKFnj6U8R_bridLBDQGwspRfn0k9JS77PbDdUeUM=.4a15b8b5-c841-46ed-a882-1dd9e1ce2394@github.com>

On Wed, 13 Nov 2024 19:58:10 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> (here and elsewhere)
>
> I usually keep it this way as it is still readable and less space. But changed the formatting so that the statement with the dot `.filter` is in the new line. This is as far as I know what most people do.

there is generally added benefit in case of an exception the line number would point to the offending code, rather than to the whole line.

it's probably not important here as we don't deal with deciphering ancient logs as much.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1635#discussion_r1841104260

From mstrauss at openjdk.org  Wed Nov 13 20:35:33 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 13 Nov 2024 20:35:33 GMT
Subject: Integrated: 8306707: Support pluggable image loading via javax.imageio
In-Reply-To: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
Message-ID: <OkNSwyflLOVQfopSTuVy7momznzKn-L_mvSYxPmxlco=.29491243-db0a-4597-b0bb-9b93d44d766a@github.com>

On Mon, 7 Oct 2024 15:13:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This PR is an improved version of #1093.
> 
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
> 
> This will probably not happen any time soon, so we are left with three alternatives:
> 1. Accept the fact that JavaFX will never be able to load additional image formats.
> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
> 3. Leverage the existing Java Image I/O API.
> 
> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
> 
> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
> 
> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
> 
> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample

This pull request has now been integrated.

Changeset: 72af9e23
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/72af9e2366727a83ca1eace73e1c337cc4f8a255
Stats:     3835 lines in 36 files changed: 3036 ins; 632 del; 167 mod

8306707: Support pluggable image loading via javax.imageio

Reviewed-by: jhendrikx, kcr, jdv

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

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

From kcr at openjdk.org  Wed Nov 13 22:06:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Nov 2024 22:06:12 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v6]
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <QSZNQQaTP6hOTXxLJBkT12EAnEf5bQqXrk4rYlcS-mI=.25e51f0c-bdda-4678-b671-0b1079aee2e2@github.com>

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

Kevin Rushforth 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 nine additional commits since the last revision:

 - Merge branch 'master' into 8342997-getSecurityManager
 - fix copy/paste error in comment
 - remove redundant override of Dragboard::getContentImpl
 - Restore mistakenly removed comment.
 - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
 - Additional cleanup of unused fields, imports, and comments related to permissions
 - Review comments: remove unused field, methods in FXMLLoader
 - 8342994: Remove security manager calls in com.sun.javafx.reflect
   Remove dead code from ReflectUtil
 - 8342997: Remove use of System::getSecurityManager and SecurityManager
   8342998: Remove all uses of AccessControlException

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1631/files
  - new: https://git.openjdk.org/jfx/pull/1631/files/159e204e..ba1a60d5

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

  Stats: 4098 lines in 40 files changed: 3298 ins; 632 del; 168 mod
  Patch: https://git.openjdk.org/jfx/pull/1631.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1631/head:pull/1631

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

From angorya at openjdk.org  Wed Nov 13 22:41:33 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 22:41:33 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
Message-ID: <MptWh_Z7srCCwwsw78-03HRs0_HddXoLsGGwxnuGJVY=.e1370e2c-7577-4b16-948a-40cc64dc479a@github.com>

On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include image size in exception message

too late to the party, but


Description	Resource	Type	Path	Location
The method load(int, double, double, boolean, boolean, float, float) of type GIFImageLoader2 should be tagged with @Override since it actually overrides a superinterface method	GIFImageLoader2.java	Java Problem	/graphics/src/main/java/com/sun/javafx/iio/gif	line 201

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2474965062

From angorya at openjdk.org  Wed Nov 13 23:35:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 23:35:57 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
Message-ID: <bnrDlgClSpzrtlqx14P4MaRCt0aWHSG_GjORio_jsk4=.1fe3f382-18a2-4fbc-ba29-6cafb5524519@github.com>

On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR is an improved version of #1093.
>> 
>> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image loaders. It has been a long-standing request to support more image formats, most notably (but not limited to) SVG. However, adding more built-in image loaders is a significant effort not only in creating the functionality, but also in maintaining the additional dependencies.
>> 
>> This will probably not happen any time soon, so we are left with three alternatives:
>> 1. Accept the fact that JavaFX will never be able to load additional image formats.
>> 2. Create a public image loader API, and hope that developers in the JavaFX ecosystem will create image loader plugins.
>> 3. Leverage the existing Java Image I/O API.
>> 
>> From these options, I think we should simply support existing Java APIs; both because it is the shortest and most realistic path forward, but also because I don't think it is sensible to bifurcate pluggable image loading in the Java ecosystem.
>> 
>> Of course, Java Image I/O is a part of the `java.desktop` module, which as of now, all JavaFX applications require. However, it has been noted in the previous PR that we shouldn't lock JavaFX into the `java.desktop` dependency even further.
>> 
>> I've improved this PR to not permanently require the `java.desktop` dependency: if the module is present, then JavaFX will use Image I/O for image formats that it can't load with the built-in loaders; if the module is not present, only the built-in loaders are available.
>> 
>> I have prepared a small sample application that showcases how the feature can be used to load SVG images in a JavaFX application: https://github.com/mstr2/jfx-imageio-sample
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include image size in exception message

nope, only this one (we've cleaned up the rest)
can you enable this warning in your IDE?
and yes, could you please create a ticket?  if not, I'll create one tomorrow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2475035968

From mstrauss at openjdk.org  Wed Nov 13 23:35:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 13 Nov 2024 23:35:56 GMT
Subject: RFR: 8306707: Support pluggable image loading via javax.imageio
 [v20]
In-Reply-To: <MptWh_Z7srCCwwsw78-03HRs0_HddXoLsGGwxnuGJVY=.e1370e2c-7577-4b16-948a-40cc64dc479a@github.com>
References: <XWcFaigmr3cRPPSelxLfnhHWbHXoc9qdMpVfhoxxhHY=.dfd99c9f-659c-437d-ac57-c99225751b16@github.com>
 <rlTRMqmfs1ilgLZzk_1NA5EWzhX3F9dCZmI1Zx_K4Cw=.40306f98-7154-47a5-bec7-23731ba90606@github.com>
 <MptWh_Z7srCCwwsw78-03HRs0_HddXoLsGGwxnuGJVY=.e1370e2c-7577-4b16-948a-40cc64dc479a@github.com>
Message-ID: <vpa_mBLKb-8sWZxPneUr9qW0tluFqDpN_iOneIVNAXI=.b854f0d4-8701-49a9-bb0f-143eebd67e3f@github.com>

On Wed, 13 Nov 2024 22:38:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> too late to the party, but
> 
> ```
> Description	Resource	Type	Path	Location
> The method load(int, double, double, boolean, boolean, float, float) of type GIFImageLoader2 should be tagged with @Override since it actually overrides a superinterface method	GIFImageLoader2.java	Java Problem	/graphics/src/main/java/com/sun/javafx/iio/gif	line 201
> ```

I'm sure there are other cases like this. Time for a clean-up ticket?

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

PR Comment: https://git.openjdk.org/jfx/pull/1593#issuecomment-2475033762

From angorya at openjdk.org  Wed Nov 13 23:36:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 23:36:50 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v42]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <_pOaV9ti9iiBn1mTKIhLYq82l-ZIhPodlf_Qx5PII5E=.c1188a8c-258d-45b9-ad97-33f5e35b960e@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  removed add handler last

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/7585ae30..5e2a68fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=41
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=40-41

  Stats: 68 lines in 4 files changed: 0 ins; 65 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Wed Nov 13 23:58:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 13 Nov 2024 23:58:11 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v4]
In-Reply-To: <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
Message-ID: <HT3-JUBFX-5vt7FTLr1qUXJDvO-E-1pTIPgTJvfhQAk=.45334185-0cf3-453e-bc03-5285e51c105e@github.com>

On Fri, 1 Nov 2024 23:39:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>  - add platform keys to javadoc
>  - Change reducedScrollBars to persistentScrollBars
>  - Add reducedScrollBars preference

the code changes look good, and both the property and the key reflect the platform preference on macOS M1 14.7.

I'll test windows tomorrow, and if someone can test it on linux, that would be fantastic!

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

PR Review: https://git.openjdk.org/jfx/pull/1618#pullrequestreview-2434706603

From mstrauss at openjdk.org  Thu Nov 14 00:01:24 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 00:01:24 GMT
Subject: RFR: 8344155: Add missing @Override annotation to GIFImageLoader2
Message-ID: <nDQgaw4L2cBVXU6A-Ux0YvFYHWYlXKnf3HXzVhtJrQ0=.8bea76aa-b209-45e9-a0fa-c3207e5e4e27@github.com>

The method `load(...)` is missing an `@Override` annotation.

A single reviewer is sufficient.

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

Commit messages:
 - Add missing Override

Changes: https://git.openjdk.org/jfx/pull/1636/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1636&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344155
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1636.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1636/head:pull/1636

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

From angorya at openjdk.org  Thu Nov 14 00:07:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 00:07:12 GMT
Subject: RFR: 8344155: Add missing @Override annotation to GIFImageLoader2
In-Reply-To: <nDQgaw4L2cBVXU6A-Ux0YvFYHWYlXKnf3HXzVhtJrQ0=.8bea76aa-b209-45e9-a0fa-c3207e5e4e27@github.com>
References: <nDQgaw4L2cBVXU6A-Ux0YvFYHWYlXKnf3HXzVhtJrQ0=.8bea76aa-b209-45e9-a0fa-c3207e5e4e27@github.com>
Message-ID: <dIq2z60fT5AcRMaKriCGnOjSC84153YkTkuvrTlYck0=.1b2c5a86-243b-457e-9a4a-1b30e0b7c7f1@github.com>

On Wed, 13 Nov 2024 23:56:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The method `load(...)` is missing an `@Override` annotation.
> 
> A single reviewer is sufficient.

thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1636#pullrequestreview-2434713834

From kcr at openjdk.org  Thu Nov 14 00:38:59 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 00:38:59 GMT
Subject: [jfx23u] RFR: 8343630: Pass AccessControlContext to/from WebKit as
 opaque object
Message-ID: <eOKhWHaY3iRJhrYx9R1z-WA2CckbdJnfxs2CxMyWNXM=.4028037f-db89-4bbf-9848-14c6c910d57d@github.com>

Clean backport, needed to keep the native WebKit in sync. I have tested this with and without a Security Manager.

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

Commit messages:
 - 8343630: Pass AccessControlContext to/from WebKit as opaque object

Changes: https://git.openjdk.org/jfx23u/pull/29/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=29&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343630
  Stats: 8 lines in 3 files changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jfx23u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/29/head:pull/29

PR: https://git.openjdk.org/jfx23u/pull/29

From arapte at openjdk.org  Thu Nov 14 08:49:32 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 14 Nov 2024 08:49:32 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
In-Reply-To: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
Message-ID: <W6kUSSQ3mvLE0kyhh_zu5AlRilBY-C-tNzjQZmO5t4Y=.9533b78d-cbe7-41dd-8df9-a1789be2c616@github.com>

On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
> 
> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
> 2. A utility class to produce warnings when first using an incubator module.
> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
> 
> See PR #1617 for a sample module that is built on top of this PR's source branch.
> 
> This is almost ready to review. I will take it out of Draft in the next day or so.

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1616#pullrequestreview-2435391619

From jvos at openjdk.org  Thu Nov 14 09:35:40 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 14 Nov 2024 09:35:40 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
In-Reply-To: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
Message-ID: <M4YAsb_9v2wRTfys7QtXKQWcnGeLYjHd6CLZuaxT54I=.3e5a91d8-0c0d-4d62-9b73-b608b7cb5c0a@github.com>

On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
> 
> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
> 2. A utility class to produce warnings when first using an incubator module.
> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
> 
> See PR #1617 for a sample module that is built on top of this PR's source branch.
> 
> This is almost ready to review. I will take it out of Draft in the next day or so.

build.gradle line 4048:

> 4046:         'controls',
> 4047: 
> 4048:         // Add an entry for each incubator module here, leaving the incubator

Can we check for the existence of a file in e.g. buildSrc/incubator.gradle instead, and if so, modify things like dependendProjects in that file?
The build.gradle is already huge and hard to understand/maintain. Every line we add to it makes it harder.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1841860992

From zjx001202 at gmail.com  Thu Nov 14 10:29:32 2024
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 14 Nov 2024 18:29:32 +0800
Subject: Class ButtonAccessibility is implemented twice in JFX 17.0.13
Message-ID: <CAJL5A3nJVK9JuJk8UhSo6Bo8cWy_=ovaxhmMqY+7XbUhxcSuZg@mail.gmail.com>

Hi,

We received a JVM crash report[1] for our JavaFX application and I noticed
it contained these lines:

objc[71933]: Class ButtonAccessibility is implemented in both
> /Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
> (0x100d6caa0) and /Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
> (0x14c4fe218). One of the two will be used. Which one is undefined.


*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
> reason: '-[ButtonAccessibility initWithEnv:accessible:]: unrecognized
> selector sent to instance 0x6000024fb540'


This crash occurred after we bumped the JavaFX from 19.0.2.1 to 17.0.13.
It looks like it's related to JDK-8311806, is it?
If yes, I'd like to request a backport of the patch that fixes it to JavaFX
17u.

Glavo

[1]: https://github.com/HMCL-dev/HMCL/issues/3409
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241114/664636c5/attachment.htm>

From arapte at openjdk.org  Thu Nov 14 12:07:05 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 14 Nov 2024 12:07:05 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds of
 JavaFX
Message-ID: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>

Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
For example:
For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.

And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
This change has no effect on a regular developer build from master branch.

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

Commit messages:
 - 8343196: Add build property to identify experimental builds of JavaFX

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

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

From arapte at openjdk.org  Thu Nov 14 12:07:05 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 14 Nov 2024 12:07:05 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <l2YCatUq9kI7C28Y9FYr_X-J89cf2CdTvuDb6PKi14s=.24178e15-29d0-47e7-ab39-34ba5dec0572@github.com>

On Thu, 14 Nov 2024 12:01:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

@kevinrushforth  Please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2476172646

From kcr at openjdk.org  Thu Nov 14 12:26:25 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 12:26:25 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules
In-Reply-To: <M4YAsb_9v2wRTfys7QtXKQWcnGeLYjHd6CLZuaxT54I=.3e5a91d8-0c0d-4d62-9b73-b608b7cb5c0a@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <M4YAsb_9v2wRTfys7QtXKQWcnGeLYjHd6CLZuaxT54I=.3e5a91d8-0c0d-4d62-9b73-b608b7cb5c0a@github.com>
Message-ID: <OIsc7nGE51DkmJpgclnEySnk3mgD_TOYnp6LT9PS3ZI=.8b3555d3-ca1c-40ad-a4f1-7fa4c138dd81@github.com>

On Thu, 14 Nov 2024 09:32:33 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
>> 
>> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
>> 2. A utility class to produce warnings when first using an incubator module.
>> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
>> 
>> See PR #1617 for a sample module that is built on top of this PR's source branch.
>> 
>> This is almost ready to review. I will take it out of Draft in the next day or so.
>
> build.gradle line 4048:
> 
>> 4046:         'controls',
>> 4047: 
>> 4048:         // Add an entry for each incubator module here, leaving the incubator
> 
> Can we check for the existence of a file in e.g. buildSrc/incubator.gradle instead, and if so, modify things like dependendProjects in that file?
> The build.gradle is already huge and hard to understand/maintain. Every line we add to it makes it harder.

That's an interesting idea. I'll prototype it and see how it looks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1842130558

From kcr at openjdk.org  Thu Nov 14 12:28:02 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 12:28:02 GMT
Subject: [jfx23u] RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode 14
 which will be removed
Message-ID: <OJw3fuARlJsdFC4SCzljL839VpkVyTrj3wScEBS7Fa8=.46b9b816-1d31-4cc6-981e-bdd2da865c48@github.com>

Clean backport of fix to avoid spurious GHA build failures.

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

Commit messages:
 - Backport d0011b21959abdcc0ee9c969e7bd5fbbccb5d4ce

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

PR: https://git.openjdk.org/jfx23u/pull/30

From kcr at openjdk.org  Thu Nov 14 15:30:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 15:30:41 GMT
Subject: [jfx23u] RFR: 8343760: GHA: macOS / aarch64 builds depend on Xcode
 14 which will be removed
In-Reply-To: <OJw3fuARlJsdFC4SCzljL839VpkVyTrj3wScEBS7Fa8=.46b9b816-1d31-4cc6-981e-bdd2da865c48@github.com>
References: <OJw3fuARlJsdFC4SCzljL839VpkVyTrj3wScEBS7Fa8=.46b9b816-1d31-4cc6-981e-bdd2da865c48@github.com>
Message-ID: <QNbCji-D9TW6VaCWQ6Cyec39ARiWP8D2yJ5E5OnyaNc=.6558b9b8-64d1-4a8a-8568-795cd6505f7a@github.com>

On Thu, 14 Nov 2024 12:22:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of fix to avoid spurious GHA build failures.

@johanvos can you approve this backport request

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

PR Comment: https://git.openjdk.org/jfx23u/pull/30#issuecomment-2476709972

From kcr at openjdk.org  Thu Nov 14 15:31:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 15:31:45 GMT
Subject: [jfx23u] RFR: 8343630: Pass AccessControlContext to/from WebKit as
 opaque object
In-Reply-To: <eOKhWHaY3iRJhrYx9R1z-WA2CckbdJnfxs2CxMyWNXM=.4028037f-db89-4bbf-9848-14c6c910d57d@github.com>
References: <eOKhWHaY3iRJhrYx9R1z-WA2CckbdJnfxs2CxMyWNXM=.4028037f-db89-4bbf-9848-14c6c910d57d@github.com>
Message-ID: <4PSf_QEHKXBB6xajkwhNl2vnfpWz9AyA9T1NMgnq8Kw=.1cddd19c-82e6-4e05-ac83-72d2818dc5e0@github.com>

On Thu, 14 Nov 2024 00:34:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport, needed to keep the native WebKit in sync. I have tested this with and without a Security Manager.

@johanvos can you approve this backport request

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

PR Comment: https://git.openjdk.org/jfx23u/pull/29#issuecomment-2476709484

From kcr at openjdk.org  Thu Nov 14 15:40:51 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 15:40:51 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <FESV8mNN195AH_j2xRzjjBUlPDZpba_KGHeJiDuatVc=.cb12aa3c-d617-4660-a4a2-b0d4afbaa9dd@github.com>

On Thu, 14 Nov 2024 12:01:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

Reviewers: @kevinrushforth  @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2476733921

From kcr at openjdk.org  Thu Nov 14 15:40:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 15:40:52 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX
In-Reply-To: <l2YCatUq9kI7C28Y9FYr_X-J89cf2CdTvuDb6PKi14s=.24178e15-29d0-47e7-ab39-34ba5dec0572@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <l2YCatUq9kI7C28Y9FYr_X-J89cf2CdTvuDb6PKi14s=.24178e15-29d0-47e7-ab39-34ba5dec0572@github.com>
Message-ID: <4SzOtAouoWo0aTEBtw4noZok2Vp-x_3F6R_koLHj6H0=.8550f826-6a42-4e18-a882-ddc1589c5cd5@github.com>

On Thu, 14 Nov 2024 12:02:02 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> @kevinrushforth  Please take a look.

@arapte Can you merge in the latest master? The macOS GHA failure is due to your being out of date.

The fix looks good to me. I'll do some testing before approving.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2476736525

From lkostyra at openjdk.org  Thu Nov 14 15:45:33 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 14 Nov 2024 15:45:33 GMT
Subject: RFR: 8342997: Remove use of System::getSecurityManager and
 SecurityManager [v6]
In-Reply-To: <QSZNQQaTP6hOTXxLJBkT12EAnEf5bQqXrk4rYlcS-mI=.25e51f0c-bdda-4678-b671-0b1079aee2e2@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
 <QSZNQQaTP6hOTXxLJBkT12EAnEf5bQqXrk4rYlcS-mI=.25e51f0c-bdda-4678-b671-0b1079aee2e2@github.com>
Message-ID: <wY4LPqIzM6JIZsngH6_OL7GFNLM6n4gu3XiG47NRTTk=.9054700e-8f16-4e39-ba8f-fed1a8e3f794@github.com>

On Wed, 13 Nov 2024 22:06:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
>> 
>> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
>> 
>> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
>> 
>> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).
>
> Kevin Rushforth 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 nine additional commits since the last revision:
> 
>  - Merge branch 'master' into 8342997-getSecurityManager
>  - fix copy/paste error in comment
>  - remove redundant override of Dragboard::getContentImpl
>  - Restore mistakenly removed comment.
>  - Replace 'TODO: SM removal:' comments with 'TODO: JDK-nnnnnnn:'
>  - Additional cleanup of unused fields, imports, and comments related to permissions
>  - Review comments: remove unused field, methods in FXMLLoader
>  - 8342994: Remove security manager calls in com.sun.javafx.reflect
>    Remove dead code from ReflectUtil
>  - 8342997: Remove use of System::getSecurityManager and SecurityManager
>    8342998: Remove all uses of AccessControlException

Looks good, verified on Windows

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1631#pullrequestreview-2436452252

From mstrauss at openjdk.org  Thu Nov 14 15:48:10 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 15:48:10 GMT
Subject: Integrated: 8344155: Add missing @Override annotation to
 GIFImageLoader2
In-Reply-To: <nDQgaw4L2cBVXU6A-Ux0YvFYHWYlXKnf3HXzVhtJrQ0=.8bea76aa-b209-45e9-a0fa-c3207e5e4e27@github.com>
References: <nDQgaw4L2cBVXU6A-Ux0YvFYHWYlXKnf3HXzVhtJrQ0=.8bea76aa-b209-45e9-a0fa-c3207e5e4e27@github.com>
Message-ID: <-NPIvmoRXDjuIdvGvdo5DfHuHLQSlyntKHg3DyZouHI=.51ecd519-893b-4e6f-a786-4084b40cdaf2@github.com>

On Wed, 13 Nov 2024 23:56:55 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The method `load(...)` is missing an `@Override` annotation.
> 
> A single reviewer is sufficient.

This pull request has now been integrated.

Changeset: 286c3a87
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/286c3a8790b01a405713d8bcc31312ce5b0d02f5
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344155: Add missing @Override annotation to GIFImageLoader2

Reviewed-by: angorya

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

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

From mfox at openjdk.org  Thu Nov 14 16:20:11 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Nov 2024 16:20:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v27]
In-Reply-To: <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
Message-ID: <ct5lxIbJIB88L2oSjclScpy9SamMuaShl5wwANEkTfs=.71c613e9-2350-4e38-957f-2e12ee067a37@github.com>

On Sat, 9 Nov 2024 07:45:19 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED` stage style](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 34 commits:
> 
>  - Merge branch 'master' into feature/extended-window
>  - Merge branch 'master' into feature/extended-window
>  - add system menu documentation
>  - WindowControlsOverlay snapping
>  - HeaderBar javadoc change
>  - refactor performWindowDrag
>  - HeaderBar changes
>  - EMPTY Dimension2D constant
>  - use CsvSource in HeaderBarTest
>  - stylistic changes
>  - ... and 24 more: https://git.openjdk.org/jfx/compare/d0011b21...65f095ef

Kudos for tackling this and doing such a thorough job. I'll try to look over the Windows code in the next couple of weeks.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacWindow.java line 176:

> 174:                 if (eventHandler != null && eventHandler.pickDragAreaNode(wx, wy) != null) {
> 175:                     if (clickCount == 2) {
> 176:                         maximize(!isMaximized());

The title bar double-click behavior is user-configurable. Unfortunately the only way to get this right is to query for an undocumented but widely-known preference.


NSString* action = [NSUserDefaults.standardUserDefaults stringForKey: @"AppleActionOnDoubleClick"];
if ([action isEqualToString: @"Minimize"]) {
    [window performMiniaturize: nil];
}
else if ([action isEqualToString: @"Maximize"]) {
    [window performZoom: nil];
}

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1148:

> 1146: - (void)performWindowDrag
> 1147: {
> 1148:     if (lastEvent != nil) {

This is correct code but it would be more bullet-proof if you used `NSApp.currentEvent` rather than `lastEvent`. I'm fine either way.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 465:

> 463:             [window->nsWindow setTitlebarAppearsTransparent:YES];
> 464:             [window->nsWindow setToolbar:[NSToolbar new]];
> 465:             [window->nsWindow setToolbarStyle:NSWindowToolbarStyleUnifiedCompact];

The presence of an empty toolbar is confusing fullscreen mode. My attempt at a fix was to add a few lines in GlassWindow+Overrides.m. In `windowWillEnterFullScreen` I added:

if (nsWindow.toolbar != nil) {
    nsWindow.toolbar.visible = NO;
}

I made the toolbar visible again in `windowDidExitFullScreen`. I tried doing this in `windowWillExitFullScreen` but it didn't work.

These delegate methods are all you need to tweak. There's still a bunch of code strewn about related to non-native fullscreen handling but it's all unused cruft.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1542:

> 1540:     GLASS_POOL_ENTER;
> 1541:     {
> 1542:         NSString* preferredLanguage = [[NSLocale preferredLanguages] objectAtIndex:0];

Is there some reason you're not using the `NSWindow.windowTitlebarLayoutDirection` property?

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

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2436362179
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842448874
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842389767
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842416159
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842465120

From mstrauss at openjdk.org  Thu Nov 14 17:11:50 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 17:11:50 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v28]
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: <OUzK8bhjClGf77goYSzDWY-IX6Firg7ozwlZKUJUY8Y=.9494c83d-4ea1-43fd-8994-806e40563b22@github.com>

> Implementation of [`EXTENDED` stage style](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 36 commits:

 - remove unneeded dll
 - Merge branch 'master' into feature/extended-window
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/addExports
 - Merge branch 'master' into feature/extended-window
 - Merge branch 'master' into feature/extended-window
 - add system menu documentation
 - WindowControlsOverlay snapping
 - HeaderBar javadoc change
 - refactor performWindowDrag
 - HeaderBar changes
 - EMPTY Dimension2D constant
 - ... and 26 more: https://git.openjdk.org/jfx/compare/286c3a87...26b81b85

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=27
  Stats: 4880 lines in 60 files changed: 4368 ins; 409 del; 103 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  Thu Nov 14 17:51:54 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 17:51:54 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v29]
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: <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>

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

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

  macOS: double-click action + fullscreen toolbar

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/26b81b85..003e9d56

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

  Stats: 41 lines in 4 files changed: 37 ins; 2 del; 2 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  Thu Nov 14 17:51:57 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 17:51:57 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v27]
In-Reply-To: <ct5lxIbJIB88L2oSjclScpy9SamMuaShl5wwANEkTfs=.71c613e9-2350-4e38-957f-2e12ee067a37@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
 <ct5lxIbJIB88L2oSjclScpy9SamMuaShl5wwANEkTfs=.71c613e9-2350-4e38-957f-2e12ee067a37@github.com>
Message-ID: <qddL-uWKGpwypf9YNkz5YfFt3CGZPuI7-VH7ffY8pRs=.a4022521-0b27-4722-88a2-0e2bf667cd13@github.com>

On Thu, 14 Nov 2024 15:43:53 GMT, Martin Fox <mfox 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 34 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - add system menu documentation
>>  - WindowControlsOverlay snapping
>>  - HeaderBar javadoc change
>>  - refactor performWindowDrag
>>  - HeaderBar changes
>>  - EMPTY Dimension2D constant
>>  - use CsvSource in HeaderBarTest
>>  - stylistic changes
>>  - ... and 24 more: https://git.openjdk.org/jfx/compare/d0011b21...65f095ef
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacWindow.java line 176:
> 
>> 174:                 if (eventHandler != null && eventHandler.pickDragAreaNode(wx, wy) != null) {
>> 175:                     if (clickCount == 2) {
>> 176:                         maximize(!isMaximized());
> 
> The title bar double-click behavior is user-configurable. Unfortunately the only way to get this right is to query for an undocumented but widely-known preference.
> 
> 
> NSString* action = [NSUserDefaults.standardUserDefaults stringForKey: @"AppleActionOnDoubleClick"];
> if ([action isEqualToString: @"Minimize"]) {
>     [window performMiniaturize: nil];
> }
> else if ([action isEqualToString: @"Maximize"]) {
>     [window performZoom: nil];
> }

Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842654963

From mstrauss at openjdk.org  Thu Nov 14 17:58:25 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 17:58:25 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v27]
In-Reply-To: <ct5lxIbJIB88L2oSjclScpy9SamMuaShl5wwANEkTfs=.71c613e9-2350-4e38-957f-2e12ee067a37@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <iHQ_S5GNwqxI2RfGeGHgdakx8G1s6ctp2b2ejaHQHoo=.125d7607-66db-4f6c-aee5-6102a84f189e@github.com>
 <ct5lxIbJIB88L2oSjclScpy9SamMuaShl5wwANEkTfs=.71c613e9-2350-4e38-957f-2e12ee067a37@github.com>
Message-ID: <6t47XGW0RGHueKNLGMhmSgNc76WtNRNWKBn33pszME4=.e0e29bbd-6241-492a-b66e-d6767ef2f267@github.com>

On Thu, 14 Nov 2024 15:53:50 GMT, Martin Fox <mfox 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 34 commits:
>> 
>>  - Merge branch 'master' into feature/extended-window
>>  - Merge branch 'master' into feature/extended-window
>>  - add system menu documentation
>>  - WindowControlsOverlay snapping
>>  - HeaderBar javadoc change
>>  - refactor performWindowDrag
>>  - HeaderBar changes
>>  - EMPTY Dimension2D constant
>>  - use CsvSource in HeaderBarTest
>>  - stylistic changes
>>  - ... and 24 more: https://git.openjdk.org/jfx/compare/d0011b21...65f095ef
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1542:
> 
>> 1540:     GLASS_POOL_ENTER;
>> 1541:     {
>> 1542:         NSString* preferredLanguage = [[NSLocale preferredLanguages] objectAtIndex:0];
> 
> Is there some reason you're not using the `NSWindow.windowTitlebarLayoutDirection` property?

It just doesn't seem to work. `NSWindow.windowTitlebarLayoutDirection` always returns `NSUserInterfaceLayoutDirectionLeftToRight`, even when my system layout direction clearly is right-to-left. I haven't been able to find out why that is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842663820

From angorya at openjdk.org  Thu Nov 14 18:22:31 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 18:22:31 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v29]
In-Reply-To: <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>
Message-ID: <zN-D4szaPzubf6cYHUw1YgOJHhoaDPIZxqlz1b9u95Y=.95f1755b-5fd8-41bc-a322-0442168e5211@github.com>

On Thu, 14 Nov 2024 17:51:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   macOS: double-click action + fullscreen toolbar

modules/javafx.graphics/src/test/addExports line 59:

> 57: --add-opens javafx.graphics/javafx.scene.paint=ALL-UNNAMED
> 58: --add-opens javafx.graphics/javafx.stage=ALL-UNNAMED
> 59: --add-opens java.desktop/javax.imageio=ALL-UNNAMED

this change seems unrelated

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842702707

From mhanl at openjdk.org  Thu Nov 14 18:54:37 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 14 Nov 2024 18:54:37 GMT
Subject: Integrated: 8344067: TableCell indices may not match the TableRow
 index
In-Reply-To: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com>
Message-ID: <ofhZ_vJvea8ppSGQJMlxdfeDIIAeeWLaw5j6hH1aWx0=.15028025-379f-4255-9066-a2a850fd1471@github.com>

On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the `TableCell` indices can be outdated (not synchronized) with the `TableRow` index.
> 
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (otherwise noop)
> - Item is changed: Cell update is requested, which will now update the indices of the underlying `TableCells`
> 
> Under some circumstances, when a `TableRow` is reused (e.g. index 60 -> 1) the item can be the same 
> -> `oldIndex != newIndex && oldItem == newItem`
> This can happen when the items of a `TableView` are changed, but some items are the same in both item lists (Think about a filter, where we filter down 60 to 2 items).
> 
> -> In this scenario, the cell update is not triggered, so the underlying `TableCell` indices will not be updated ever (e.g. they still have index 60 set, but the row has 1 now). 
> 
> The fix is to always update the underlying `TableCell` indices when the `TableRow` index changed. 
> While usually the item is different when the index changed, this is not always the case (there is no guarantee that the item changed, as we can see in the example, where the cell is reused).
> 
> ---
> 
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269

This pull request has now been integrated.

Changeset: b0e763c1
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b0e763c12729bf30a04716bccadf5ff94c4a4bd7
Stats:     169 lines in 5 files changed: 160 ins; 8 del; 1 mod

8344067: TableCell indices may not match the TableRow index

Reviewed-by: angorya

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

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

From mstrauss at openjdk.org  Thu Nov 14 19:02:26 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 19:02:26 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v29]
In-Reply-To: <zN-D4szaPzubf6cYHUw1YgOJHhoaDPIZxqlz1b9u95Y=.95f1755b-5fd8-41bc-a322-0442168e5211@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>
 <zN-D4szaPzubf6cYHUw1YgOJHhoaDPIZxqlz1b9u95Y=.95f1755b-5fd8-41bc-a322-0442168e5211@github.com>
Message-ID: <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com>

On Thu, 14 Nov 2024 18:19: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:
>> 
>>   macOS: double-click action + fullscreen toolbar
>
> modules/javafx.graphics/src/test/addExports line 59:
> 
>> 57: --add-opens javafx.graphics/javafx.scene.paint=ALL-UNNAMED
>> 58: --add-opens javafx.graphics/javafx.stage=ALL-UNNAMED
>> 59: --add-opens java.desktop/javax.imageio=ALL-UNNAMED
> 
> this change seems unrelated

`WindowControlsOverlayTest.activePseudoClassCorrespondsToStageFocusedProperty()` requires `opens javafx.stage`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842749731

From angorya at openjdk.org  Thu Nov 14 19:08:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 19:08:07 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v29]
In-Reply-To: <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>
 <zN-D4szaPzubf6cYHUw1YgOJHhoaDPIZxqlz1b9u95Y=.95f1755b-5fd8-41bc-a322-0442168e5211@github.com>
 <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com>
Message-ID: <tcyuvDLdfKbFeAimpPa3XfIorrIopfa7EZQnDkqIZBg=.72ad6a1f-9064-4e10-bb7b-b82886cbb4fb@github.com>

On Thu, 14 Nov 2024 18:59:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/addExports line 59:
>> 
>>> 57: --add-opens javafx.graphics/javafx.scene.paint=ALL-UNNAMED
>>> 58: --add-opens javafx.graphics/javafx.stage=ALL-UNNAMED
>>> 59: --add-opens java.desktop/javax.imageio=ALL-UNNAMED
>> 
>> this change seems unrelated
>
> `WindowControlsOverlayTest.activePseudoClassCorrespondsToStageFocusedProperty()` requires `opens javafx.stage`.

the question is about `java.desktop/javax.imageio` not `javafx.graphics/javafx.stage` or am I missing something?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842754779

From mstrauss at openjdk.org  Thu Nov 14 19:12:18 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 19:12:18 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v29]
In-Reply-To: <tcyuvDLdfKbFeAimpPa3XfIorrIopfa7EZQnDkqIZBg=.72ad6a1f-9064-4e10-bb7b-b82886cbb4fb@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <ZJxKfuqM8bcFUmPY642uE3wFFBxB9oUNGyzLQ5qqIZY=.ac5746a9-54a5-4737-8376-ed55602d1600@github.com>
 <zN-D4szaPzubf6cYHUw1YgOJHhoaDPIZxqlz1b9u95Y=.95f1755b-5fd8-41bc-a322-0442168e5211@github.com>
 <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com>
 <tcyuvDLdfKbFeAimpPa3XfIorrIopfa7EZQnDkqIZBg=.72ad6a1f-9064-4e10-bb7b-b82886cbb4fb@github.com>
Message-ID: <QrFSNOE0Pr1J3ErJschTe-SNZ9Lpf7wljHNLWVWdiik=.de95733a-48d9-476c-b0e7-2bd50feda097@github.com>

On Thu, 14 Nov 2024 19:03:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `WindowControlsOverlayTest.activePseudoClassCorrespondsToStageFocusedProperty()` requires `opens javafx.stage`.
>
> the question is about `java.desktop/javax.imageio` not `javafx.graphics/javafx.stage` or am I missing something?

Not sure why GitHub highlights this line as changed, because it's not. The line that has actually changed is
`--add-opens javafx.graphics/javafx.stage=ALL-UNNAMED`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1842761284

From kevin.rushforth at oracle.com  Thu Nov 14 20:09:52 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 14 Nov 2024 12:09:52 -0800
Subject: Class ButtonAccessibility is implemented twice in JFX 17.0.13
In-Reply-To: <CAJL5A3nJVK9JuJk8UhSo6Bo8cWy_=ovaxhmMqY+7XbUhxcSuZg@mail.gmail.com>
References: <CAJL5A3nJVK9JuJk8UhSo6Bo8cWy_=ovaxhmMqY+7XbUhxcSuZg@mail.gmail.com>
Message-ID: <f721bdc5-8b90-4d60-9c9e-cd9a85044de1@oracle.com>

This does look like JDK-8311806.

Gluon maintains jfx17u, so Johan can comment on your request.

-- Kevin


On 11/14/2024 2:29 AM, Glavo wrote:
> Hi,
>
> We received a JVM crash report[1] for our JavaFX application and I 
> noticed it contained these lines:
>
>     objc[71933]: Class ButtonAccessibility is implemented in both
>     /Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
>     (0x100d6caa0) and
>     /Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
>     (0x14c4fe218). One of the two will be used. Which one is undefined.
>
>
>     *** Terminating app due to uncaught exception
>     'NSInvalidArgumentException', reason: '-[ButtonAccessibility
>     initWithEnv:accessible:]: unrecognized selector sent to instance
>     0x6000024fb540'
>
>
> This crash occurred after we bumped the JavaFX from 19.0.2.1 to 17.0.13.
> It looks like it's related to JDK-8311806, is it?
> If yes, I'd like to request a backport of the patch that fixes it to 
> JavaFX 17u.
>
> Glavo
>
> [1]: https://github.com/HMCL-dev/HMCL/issues/3409
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241114/88b80918/attachment-0001.htm>

From kcr at openjdk.org  Thu Nov 14 20:19:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 20:19:40 GMT
Subject: Integrated: 8342997: Remove use of System::getSecurityManager and
 SecurityManager from JavaFX
In-Reply-To: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
References: <MB2em6bzWBJDdmDxuaLOIJOUodCea0ChHb8VQMThKR8=.5717e0cb-ec9f-4b8f-92f1-b5861c98f0ad@github.com>
Message-ID: <d-4mN84XfoH6Ht0kT_G6bkrKixGjk2zWKjjW4Y3THwE=.6be1fb94-92f3-4131-afee-3864a903ffeb@github.com>

On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Ths PR removes all remaining calls to `System::getSecurityManager` and the `SecurityManager` class along with the `System.getGecurityManager() != null` code paths.
> 
> As part of doing this, the last uses of `PermissionHelper` and `FXPermissions` were eliminated, so I deleted those two classes. Since `PermissionHelper` was the last remaining use of `AccessControlException`, I am adding JDK-8342998 to this PR.
> 
> In a few places, I noted some "check permissions" methods that are now no-ops that might be candidates for further cleanup (not directly related, so not planned for jfx24).
> 
> Finally, I deleted several unused methods in `MethodUtil` and `ReflectUtil` (some of these were already removed in the corresponding JDK classes, and some of them were unused after the changes to remove the call to `getSecurityManager`).

This pull request has now been integrated.

Changeset: dd600658
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/dd60065808bc847d8efbb818b8f83c4e61290d29
Stats:     911 lines in 33 files changed: 10 ins; 866 del; 35 mod

8342997: Remove use of System::getSecurityManager and SecurityManager from JavaFX
8342998: Remove all uses of AccessControlException
8342994: Remove security manager calls in com.sun.javafx.reflect

Reviewed-by: angorya, lkostyra

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

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

From angorya at openjdk.org  Thu Nov 14 20:22:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 20:22:07 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v43]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <cLJejS2fJMvcW4QXAKB2l5vJejJwhSnd5uwgqf_u6Mc=.27ee10be-cdae-4ddb-bcce-652e121c9cfd@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  removed function handler

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/5e2a68fb..ff3f5afe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=42
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=41-42

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

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

From kcr at openjdk.org  Thu Nov 14 20:56:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 20:56:09 GMT
Subject: [jfx23u] Integrated: 8343760: GHA: macOS / aarch64 builds depend on
 Xcode 14 which will be removed
In-Reply-To: <OJw3fuARlJsdFC4SCzljL839VpkVyTrj3wScEBS7Fa8=.46b9b816-1d31-4cc6-981e-bdd2da865c48@github.com>
References: <OJw3fuARlJsdFC4SCzljL839VpkVyTrj3wScEBS7Fa8=.46b9b816-1d31-4cc6-981e-bdd2da865c48@github.com>
Message-ID: <5ibU7j_jMVNEE5LsIJWHliwHqG6TFYHTS_x4pT2SFMY=.6c481da7-c3b6-449f-9d47-99de4ae2ed65@github.com>

On Thu, 14 Nov 2024 12:22:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of fix to avoid spurious GHA build failures.

This pull request has now been integrated.

Changeset: 2e057b76
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/2e057b76e80051387d7dbf8990d5e7e8597e97b5
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8343760: GHA: macOS / aarch64 builds depend on Xcode 14 which will be removed

Backport-of: d0011b21959abdcc0ee9c969e7bd5fbbccb5d4ce

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

PR: https://git.openjdk.org/jfx23u/pull/30

From mstrauss at openjdk.org  Thu Nov 14 21:33:20 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 21:33:20 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v30]
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: <z_kwhWt1xBJsTiwJea7dJ_LJOlhHXtVVBa7cQp7ZBuo=.77d7ecc6-23b8-4223-a658-e1b8a4f66516@github.com>

> Implementation of [`EXTENDED` stage style](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 38 commits:

 - Merge branch 'master' into feature/extended-window
 - macOS: double-click action + fullscreen toolbar
 - remove unneeded dll
 - Merge branch 'master' into feature/extended-window
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/addExports
 - Merge branch 'master' into feature/extended-window
 - Merge branch 'master' into feature/extended-window
 - add system menu documentation
 - WindowControlsOverlay snapping
 - HeaderBar javadoc change
 - refactor performWindowDrag
 - ... and 28 more: https://git.openjdk.org/jfx/compare/dd600658...485a9d95

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=29
  Stats: 4915 lines in 61 files changed: 4403 ins; 409 del; 103 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 mhanl at openjdk.org  Thu Nov 14 21:52:57 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 14 Nov 2024 21:52:57 GMT
Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal
 scrolling [v6]
In-Reply-To: <wO0y2Cwhf0Vv4eXp3tLgrUsL4FeD05xwaoaoiljbEdc=.d4360414-de97-465a-aa6c-89e92931de8a@github.com>
References: <wO0y2Cwhf0Vv4eXp3tLgrUsL4FeD05xwaoaoiljbEdc=.d4360414-de97-465a-aa6c-89e92931de8a@github.com>
Message-ID: <QFUZk3aELCqk_IR-xKaobyLB9E2XFNuhvvf0kohWKYY=.4a16a114-9aeb-42e8-85fc-4b4423eaaa4e@github.com>

> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`.
> 
> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors.
> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object.
> 
> So the following code is effectively doing the same:
> 
> Old:
> 
> BaseBounds newClip = clipNode.getShape().getBounds();
> if (!clipNode.getTransform().isIdentity()) {
>     newClip = clipNode.getTransform().transform(newClip, newClip);
> }
> final BaseTransform curXform = g.getTransformNoClone();
> final Rectangle curClip = g.getClipRectNoClone();
> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning
> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g));
> Rectangle clipRect = new Rectangle(newClip)
> 
> 
> New:
> 
> BaseTransform curXform = g.getTransformNoClone();
> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform);
> Rectangle clipRect = new Rectangle(clipBounds);
> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g));
> 
> 
> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds.
> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug.
> 
> I checked several scenarios and code and could not find any regressions.
> Still, since this is change affects all nodes with rectangular clips, we should be careful.
> Performance wise I could not spot any difference, I do not expect any difference.
> **So I would like to have at least 2 reviewers.**
> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference.
> 
> ---
> 
> As written in the other PR, I have some interesting findings on this particular problem.
> 
> Copy&Paste from the other PR:
> --
> 
> Ok, so I found out the following:
> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering.
> This happens at the low level (`NGNode`) side of JavaFX.
> ...
> I could track it down to be a typical floating point problem
> ...
> The bug always appear...

Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix
   
   # Conflicts:
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java
 - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix
   
   # Conflicts:
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java
   #	modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java
 - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix
   
   # Conflicts:
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java
   #	modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java
 - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java
 - Improve test
 - 8218745: TableView: visual glitch at borders on horizontal scrolling

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

Changes: https://git.openjdk.org/jfx/pull/1462/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=05
  Stats: 239 lines in 11 files changed: 163 ins; 56 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1462.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1462/head:pull/1462

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

From kcr at openjdk.org  Thu Nov 14 22:16:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 22:16:45 GMT
Subject: [jfx23u] Integrated: 8343630: Pass AccessControlContext to/from WebKit
 as opaque object
In-Reply-To: <eOKhWHaY3iRJhrYx9R1z-WA2CckbdJnfxs2CxMyWNXM=.4028037f-db89-4bbf-9848-14c6c910d57d@github.com>
References: <eOKhWHaY3iRJhrYx9R1z-WA2CckbdJnfxs2CxMyWNXM=.4028037f-db89-4bbf-9848-14c6c910d57d@github.com>
Message-ID: <X6qlqPqj6DxO1wUnmOxuYAjomdp1RyaDFQ_Qc8QvIng=.01b5559a-42f5-49a7-b4fb-39dbe7bcb6a5@github.com>

On Thu, 14 Nov 2024 00:34:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport, needed to keep the native WebKit in sync. I have tested this with and without a Security Manager.

This pull request has now been integrated.

Changeset: ea0ffaaa
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/ea0ffaaa9f2de7289bdf924b3a601315f711ad73
Stats:     8 lines in 3 files changed: 2 ins; 1 del; 5 mod

8343630: Pass AccessControlContext to/from WebKit as opaque object

Backport-of: fffa0fc4fd0f2ac332ae616066579c3b6b5a9861

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

PR: https://git.openjdk.org/jfx23u/pull/29

From kcr at openjdk.org  Thu Nov 14 22:40:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 22:40:39 GMT
Subject: RFR: 8342993: Remove uses of AccessController and AccessControlContext
 from JavaFX
Message-ID: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>

This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.

With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.

### Notes to reviewers

* Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
* The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.

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

Commit messages:
 - 8342993: Remove uses of AccessController and AccessControlContext from JavaFX

Changes: https://git.openjdk.org/jfx/pull/1638/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1638&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342993
  Stats: 324 lines in 30 files changed: 7 ins; 260 del; 57 mod
  Patch: https://git.openjdk.org/jfx/pull/1638.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1638/head:pull/1638

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

From kcr at openjdk.org  Thu Nov 14 22:40:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 22:40:40 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX
In-Reply-To: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
Message-ID: <dAvmuFTmmhccBYSJ2lUUujEklklkmWjh6aAeWroEJzI=.dfc61de1-2f5b-4d56-b3a5-d54bf2f7d38f@github.com>

On Thu, 14 Nov 2024 20:59:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
> 
> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
> 
> ### Notes to reviewers
> 
> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.

Reviewers: @arapte @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1638#issuecomment-2477540942

From kcr at openjdk.org  Thu Nov 14 22:53:06 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Nov 2024 22:53:06 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
Message-ID: <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>

> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
> 
> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
> 
> ### Notes to reviewers
> 
> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  additional comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1638/files
  - new: https://git.openjdk.org/jfx/pull/1638/files/793a0aa5..f01faa1e

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

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

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

From angorya at openjdk.org  Thu Nov 14 22:58:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 22:58:11 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v4]
In-Reply-To: <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
Message-ID: <E4BEzLW8fV7nfRJGqL1maPByupkUQ0Slyk0zatygOrE=.e23ac70c-10d0-46bb-b4ba-6c5dd097d770@github.com>

On Fri, 1 Nov 2024 23:39:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>  - add platform keys to javadoc
>  - Change reducedScrollBars to persistentScrollBars
>  - Add reducedScrollBars preference

looks good on win11, both property and windows key get updated in the monkey tester.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1618#pullrequestreview-2437356277

From mstrauss at openjdk.org  Thu Nov 14 23:19:10 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 23:19:10 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
Message-ID: <BkilYQV6-7OADPy52Cy5MXbabTSgl8y55r0UAgDcHms=.8b22a82c-9a78-4580-b4a8-2e492fce1131@github.com>

On Thu, 14 Nov 2024 22:53:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
>> 
>> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
>> 
>> ### Notes to reviewers
>> 
>> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
>> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional comments

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 375:

> 373:     // than a HashSet of WeakReferences so that the entries are automatically
> 374:     // removed after the listener is garbage collected.
> 375:     private final Map<TKPulseListener,Object> stagePulseListeners = new WeakHashMap<>();

I recommend using a set instead of a map, which is a bit less confusing:

private final Set<TKPulseListener> stagePulseListeners = Collections.newSetFromMap(new WeakHashMap<>())

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1842999538

From angorya at openjdk.org  Thu Nov 14 23:45:31 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 23:45:31 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
Message-ID: <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>

On Thu, 14 Nov 2024 22:53:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
>> 
>> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
>> 
>> ### Notes to reviewers
>> 
>> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
>> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional comments

looks good, with some minor comments.

I don't know if @mstr2 's idea of converting weak hash maps to sets would help, since it does not save any memory (might actually eat more memory).  putting a `null` value might reduce the memory footprint, but needs to be checked if it would work, and putting a Boolea.TRUE would work without adding a dummy object.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 98:

> 96: 
> 97:     // Used as the (dummy) value for the various listener maps
> 98:     private static final Object dummyObj = new Object();

minor: maybe use all-uppercase name for this static final object?

we could also be using Boolean.TRUE (or null), since there is a comment down below explaining the purpose of these maps.

curiously, there is no WeakHashSet.

modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 45:

> 43:     // We do this, rather than removing the parameter, in order to keep the
> 44:     // native WebKit code the same across different release families.
> 45:     private static final Object dummyAcc = new Object();

very minor: all uppercase name

modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 120:

> 118:     public void setSlot(int index, Object value) throws JSException {
> 119:         Invoker.getInvoker().checkEventThread();
> 120:         setSlotImpl(peer, peer_type, index, value,dummyAcc);

missing space after `,`

modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 129:

> 127:     public Object call(String methodName, Object... args) throws JSException {
> 128:         Invoker.getInvoker().checkEventThread();
> 129:         return callImpl(peer, peer_type, methodName, args,dummyAcc);

missing space after `,`

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

PR Review: https://git.openjdk.org/jfx/pull/1638#pullrequestreview-2437376185
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1842997206
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1843010983
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1843011173
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1843011305

From mstrauss at openjdk.org  Thu Nov 14 23:53:12 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 14 Nov 2024 23:53:12 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
 <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>
Message-ID: <qQFbVQKICzasZv4x4jhrG-77TOxOxMRapabublzG-pw=.650275c8-536c-4709-87ea-c69c994359e7@github.com>

On Thu, 14 Nov 2024 23:11:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional comments
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 98:
> 
>> 96: 
>> 97:     // Used as the (dummy) value for the various listener maps
>> 98:     private static final Object dummyObj = new Object();
> 
> minor: maybe use all-uppercase name for this static final object?
> 
> we could also be using Boolean.TRUE (or null), since there is a comment down below explaining the purpose of these maps.
> 
> curiously, there is no WeakHashSet.

There is no need for `WeakHashSet`, because it would be equivalent to `Collections.newSetFromMap(new WeakHashMap<>())`.
`HashSet` already uses `HashMap` in its implementation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1843018433

From angorya at openjdk.org  Thu Nov 14 23:53:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 14 Nov 2024 23:53:12 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <qQFbVQKICzasZv4x4jhrG-77TOxOxMRapabublzG-pw=.650275c8-536c-4709-87ea-c69c994359e7@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
 <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>
 <qQFbVQKICzasZv4x4jhrG-77TOxOxMRapabublzG-pw=.650275c8-536c-4709-87ea-c69c994359e7@github.com>
Message-ID: <LoMOrY6y18J1543h_FdYXNMstThikzApTrp3eOC64iQ=.f588c835-3dae-42df-9114-01a2d53588c0@github.com>

On Thu, 14 Nov 2024 23:45:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 98:
>> 
>>> 96: 
>>> 97:     // Used as the (dummy) value for the various listener maps
>>> 98:     private static final Object dummyObj = new Object();
>> 
>> minor: maybe use all-uppercase name for this static final object?
>> 
>> we could also be using Boolean.TRUE (or null), since there is a comment down below explaining the purpose of these maps.
>> 
>> curiously, there is no WeakHashSet.
>
> There is no need for `WeakHashSet`, because it would be equivalent to `Collections.newSetFromMap(new WeakHashMap<>())`.
> `HashSet` already uses `HashMap` in its implementation.

wow, I did not they _cut corners_ there.  who is going to look after little peo^H^H^H bytes?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1843020897

From azvegint at openjdk.org  Fri Nov 15 02:10:51 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 15 Nov 2024 02:10:51 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session overlaps
 with an FX ScreenCast session
Message-ID: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>

This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)

It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.

The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.

---- 

Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
This is to reduce overhead in case of frequent consecutive screen captures.

When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).

It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).

So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.

[jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)

----

The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
But if the JDK and JavaFX have the fixes, everything works fine.
Testing in other different scenarios also looks good.

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

Commit messages:
 - 8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session

Changes: https://git.openjdk.org/jfx/pull/1639/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335469
  Stats: 156 lines in 3 files changed: 150 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1639.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1639/head:pull/1639

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

From azvegint at openjdk.org  Fri Nov 15 02:21:57 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 15 Nov 2024 02:21:57 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
Message-ID: <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>

> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
> 
> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
> 
> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
> 
> ---- 
> 
> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
> This is to reduce overhead in case of frequent consecutive screen captures.
> 
> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
> 
> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
> 
> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
> 
> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
> 
> ----
> 
> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
> But if the JDK and JavaFX have the fixes, everything works fine.
> Testing in other different scenarios also looks good.

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - test cleanup
 - add missing copyright header

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1639/files
  - new: https://git.openjdk.org/jfx/pull/1639/files/dba8a887..eb273f0c

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

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

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

From arapte at openjdk.org  Fri Nov 15 05:48:15 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 15 Nov 2024 05:48:15 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

Ambarish Rapte 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 'master' into exp-suffix
 - 8343196: Add build property to identify experimental builds of JavaFX

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1637/files
  - new: https://git.openjdk.org/jfx/pull/1637/files/355dec52..c3395cce

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

  Stats: 5727 lines in 119 files changed: 3565 ins; 1778 del; 384 mod
  Patch: https://git.openjdk.org/jfx/pull/1637.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1637/head:pull/1637

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

From johan.vos at gluonhq.com  Fri Nov 15 09:10:09 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 15 Nov 2024 10:10:09 +0100
Subject: Class ButtonAccessibility is implemented twice in JFX 17.0.13
In-Reply-To: <f721bdc5-8b90-4d60-9c9e-cd9a85044de1@oracle.com>
References: <CAJL5A3nJVK9JuJk8UhSo6Bo8cWy_=ovaxhmMqY+7XbUhxcSuZg@mail.gmail.com>
 <f721bdc5-8b90-4d60-9c9e-cd9a85044de1@oracle.com>
Message-ID: <CABxFH2GFyiNfg1xaEavQJ+X6sWNAXFyAt2evTY1LUE1hTK1MPw@mail.gmail.com>

This is a good question. JDK-8311806 is a P4 bug, so my (non-formal)
algorithm would say not to backport this. But then, this clearly can create
crashes and it is a simple fix that is not affecting other platforms, so I
am very much in favour of backporting it. Note that I raised this point on
the jdk-dev list [1] and it is discussed there as well [2].
>From those discussions, it becomes clear that a formal algorithm is most
likely not enough, and there should always be room for manual judgement.

In this particular case, I would vote +1 for backporting it.

- Johan

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009625.html
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009629.html


On Thu, Nov 14, 2024 at 9:10?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> This does look like JDK-8311806.
>
> Gluon maintains jfx17u, so Johan can comment on your request.
>
> -- Kevin
>
>
> On 11/14/2024 2:29 AM, Glavo wrote:
>
> Hi,
>
> We received a JVM crash report[1] for our JavaFX application and I noticed
> it contained these lines:
>
> objc[71933]: Class ButtonAccessibility is implemented in both
>> /Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
>> (0x100d6caa0) and /Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
>> (0x14c4fe218). One of the two will be used. Which one is undefined.
>
>
> *** Terminating app due to uncaught exception
>> 'NSInvalidArgumentException', reason: '-[ButtonAccessibility
>> initWithEnv:accessible:]: unrecognized selector sent to instance
>> 0x6000024fb540'
>
>
> This crash occurred after we bumped the JavaFX from 19.0.2.1 to 17.0.13.
> It looks like it's related to JDK-8311806, is it?
> If yes, I'd like to request a backport of the patch that fixes it to
> JavaFX 17u.
>
> Glavo
>
> [1]: https://github.com/HMCL-dev/HMCL/issues/3409
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/065bfc9e/attachment.htm>

From jvos at openjdk.org  Fri Nov 15 09:34:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 15 Nov 2024 09:34:41 GMT
Subject: [jfx17u] RFR: 8311806: Class ButtonAccessibility is implemented twice
Message-ID: <EydvQXvHLfKB0pTBJrTQSrK-_Hfy1N5Yy0tQzhgSmqk=.8304fdc9-4300-4e76-9409-62d5c9fa6299@github.com>

8311806: Class ButtonAccessibility is implemented twice

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

Commit messages:
 - Backport ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197

Changes: https://git.openjdk.org/jfx17u/pull/209/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311806
  Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx17u/pull/209.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/209/head:pull/209

PR: https://git.openjdk.org/jfx17u/pull/209

From kcr at openjdk.org  Fri Nov 15 12:57:15 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Nov 2024 12:57:15 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
Message-ID: <SBVF6DtupVU87KfhxsVsMnUYf5q3UetuI1THBfE8iSg=.667e95cf-e1ec-4425-a6fe-0770b734336a@github.com>

On Fri, 15 Nov 2024 02:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - test cleanup
>  - add missing copyright header

@azvegint All of the GHA builds failed with what looks like an infra problem (connection to `download.eclipse.org` failed). Can you rerun it?

I'll test this both with and without the JDK fix for openjdk/jdk#22131

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2478749887

From arapte at openjdk.org  Fri Nov 15 13:05:51 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 15 Nov 2024 13:05:51 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX
In-Reply-To: <l2YCatUq9kI7C28Y9FYr_X-J89cf2CdTvuDb6PKi14s=.24178e15-29d0-47e7-ab39-34ba5dec0572@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <l2YCatUq9kI7C28Y9FYr_X-J89cf2CdTvuDb6PKi14s=.24178e15-29d0-47e7-ab39-34ba5dec0572@github.com>
Message-ID: <4gbUJZIxlqmkGtzdm1Z0mY0xmEYppORnVBpMdOwvvuU=.6bdba870-dd50-41ad-b827-57372c2ddeb0@github.com>

On Thu, 14 Nov 2024 12:02:02 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> @kevinrushforth  Please take a look.

> @arapte Can you merge in the latest master?

Thanks @kevinrushforth , The checks pass after merging in the latest master.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2478766562

From kevin.rushforth at oracle.com  Fri Nov 15 13:13:35 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 15 Nov 2024 05:13:35 -0800
Subject: [External] : Re: Class ButtonAccessibility is implemented twice
 in JFX 17.0.13
In-Reply-To: <CABxFH2GFyiNfg1xaEavQJ+X6sWNAXFyAt2evTY1LUE1hTK1MPw@mail.gmail.com>
References: <CAJL5A3nJVK9JuJk8UhSo6Bo8cWy_=ovaxhmMqY+7XbUhxcSuZg@mail.gmail.com>
 <f721bdc5-8b90-4d60-9c9e-cd9a85044de1@oracle.com>
 <CABxFH2GFyiNfg1xaEavQJ+X6sWNAXFyAt2evTY1LUE1hTK1MPw@mail.gmail.com>
Message-ID: <66c5a0c9-5169-4a68-8b6b-600ffa7bd60c@oracle.com>

FWIW, since it is crashing, I would suggest that the priority -- at 
least for jfx17u -- is higher than a P4 (maybe a P2). We usually don't 
take the time to adjust the priority of a bug after it is fixed, so we 
will sometimes backport bugs with a lower priority than would otherwise 
meet the criteria. This one seems to be a good candidate.

-- Kevin


On 11/15/2024 1:10 AM, Johan Vos wrote:
> This is a good question.?JDK-8311806 is a P4 bug, so my (non-formal) 
> algorithm would say not to backport this. But then, this clearly can 
> create crashes and it is a simple fix that is not affecting other 
> platforms, so I am very much in favour of backporting it. Note that I 
> raised this point on the jdk-dev list [1] and it is discussed there as 
> well [2].
> From those discussions, it becomes clear that a formal algorithm is 
> most likely not enough, and there should always be room for manual 
> judgement.
>
> In this particular case, I would vote?+1 for backporting it.
>
> - Johan
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009625.html
> [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009629.html
>
>
> On Thu, Nov 14, 2024 at 9:10?PM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     This does look like JDK-8311806.
>
>     Gluon maintains jfx17u, so Johan can comment on your request.
>
>     -- Kevin
>
>
>     On 11/14/2024 2:29 AM, Glavo wrote:
>>     Hi,
>>
>>     We received a JVM crash report[1] for our JavaFX application and
>>     I noticed it contained these lines:
>>
>>         objc[71933]: Class ButtonAccessibility is implemented in both
>>         /Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
>>         (0x100d6caa0) and
>>         /Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
>>         (0x14c4fe218). One of the two will be used. Which one is
>>         undefined.
>>
>>
>>         *** Terminating app due to uncaught exception
>>         'NSInvalidArgumentException', reason: '-[ButtonAccessibility
>>         initWithEnv:accessible:]: unrecognized selector sent to
>>         instance 0x6000024fb540'
>>
>>
>>     This crash occurred after we bumped the JavaFX from 19.0.2.1 to
>>     17.0.13.
>>     It looks like it's related to JDK-8311806, is it?
>>     If yes, I'd like to request a backport of the patch that fixes it
>>     to JavaFX 17u.
>>
>>     Glavo
>>
>>     [1]: https://github.com/HMCL-dev/HMCL/issues/3409
>>     <https://urldefense.com/v3/__https://github.com/HMCL-dev/HMCL/issues/3409__;!!ACWV5N9M2RV99hQ!KZkzzMzZlUfRU2ulegM9--jXQFdjQolE3yM3RY7rkwDpxK9I5PhT-0FqrK421kvw9uZOJbfrLYWWdyw2L16FIavtWw$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/95579d89/attachment-0001.htm>

From azvegint at openjdk.org  Fri Nov 15 13:58:53 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 15 Nov 2024 13:58:53 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <SBVF6DtupVU87KfhxsVsMnUYf5q3UetuI1THBfE8iSg=.667e95cf-e1ec-4425-a6fe-0770b734336a@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
 <SBVF6DtupVU87KfhxsVsMnUYf5q3UetuI1THBfE8iSg=.667e95cf-e1ec-4425-a6fe-0770b734336a@github.com>
Message-ID: <NyBXhtrHfN2pF7edO2OJiCJw1Aq44kEuuA5MgscsSWE=.d552bc34-0567-426c-9931-1f2b7a48d579@github.com>

On Fri, 15 Nov 2024 12:53:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Can you rerun it?

Sure, done

https://github.com/azvegint/jfx/actions/runs/11849042656

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2478894882

From jvos at openjdk.org  Fri Nov 15 14:45:21 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 15 Nov 2024 14:45:21 GMT
Subject: [jfx17u] Integrated: 8311806: Class ButtonAccessibility is implemented
 twice
In-Reply-To: <EydvQXvHLfKB0pTBJrTQSrK-_Hfy1N5Yy0tQzhgSmqk=.8304fdc9-4300-4e76-9409-62d5c9fa6299@github.com>
References: <EydvQXvHLfKB0pTBJrTQSrK-_Hfy1N5Yy0tQzhgSmqk=.8304fdc9-4300-4e76-9409-62d5c9fa6299@github.com>
Message-ID: <GwhVWOiQyIZIO6J9yQIIKjc4i64ws1mrltd4Id2wdXc=.92378a8f-19f9-4fb7-b22a-86d367ea4852@github.com>

On Fri, 15 Nov 2024 09:29:17 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8311806: Class ButtonAccessibility is implemented twice

This pull request has now been integrated.

Changeset: 00dc6895
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/00dc6895117b2aff8a5120ce9d32bc8317a704a5
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8311806: Class ButtonAccessibility is implemented twice

Backport-of: ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197

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

PR: https://git.openjdk.org/jfx17u/pull/209

From ashley.hales at ntlworld.com  Fri Nov 15 15:14:27 2024
From: ashley.hales at ntlworld.com (Ashley Hales)
Date: Fri, 15 Nov 2024 15:14:27 -0000
Subject: Scene 3D objects throw exception on Android devices
Message-ID: <003f01db3771$1022a660$3067f320$@ntlworld.com>

Hi,

I posted a thread some time ago about Scene 3D objects causing a error when
they try to create the shader.  At the time I was advised to recompile the
project using the new Gluon library rather than JavaFXPorts.  I have now
done this but the result is not compatible with my device.  I have found
that the Gluon project works fine on a Motorola device running Android 13
and the JavaFXPorts project works on an old Samsung device running Android
4.4.2.  However the Gluon project won't even install on my intended target
device, which is an MBOX running Android 6.0.1, but the JavaFXPorts project
installs fine but throws ?'java.lang.RuntimeException: Error creating shader
program' on the MBOX.  I have found that the MBOX will run projects not
containing any 3D objects, for example the two sample projects included in
the Dalvik SDK - Ensemble8 and HelloAndroid - work fine.  Is there any way
around this using the JavaFXPorts technology as this has produced the best
results?  When I try to do a push install to  the MBOX using ADB it gives an
error of 'Failure [INSTALL_FAILED_NO_MATCHING_ABIS]'.  My searches online
indicate that this may be due to the version of the NDK it was compiled with
but I have found that the project only seems to compile with the Android 21
NDK.

Thanks for your help,

Ashley


-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

From angorya at openjdk.org  Fri Nov 15 17:30:59 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 15 Nov 2024 17:30:59 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v44]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <uejDHFFZr0-4_Bsk6kHktCMuQjEVJ5ktiUItMssBq5Q=.d9156a32-ccda-4e9a-b614-8daa2325268e@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  save as

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/ff3f5afe..6a02a757

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=43
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=42-43

  Stats: 109 lines in 4 files changed: 69 ins; 30 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Fri Nov 15 17:36:25 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 15 Nov 2024 17:36:25 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v45]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <mobHzpOZD1lKIu8tFzfrnvUrB7OTHt335OgfPbIbMN0=.af5ab377-383f-40ad-85eb-a405f1c2f895@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - save as
 - removed function handler
 - removed add handler last
 - use focus traversal api
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - settings
 - comment
 - review comments
 - ... and 53 more: https://git.openjdk.org/jfx/compare/dd600658...52a7dba1

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=44
  Stats: 40118 lines in 210 files changed: 40104 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From nlisker at gmail.com  Fri Nov 15 19:14:13 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 15 Nov 2024 21:14:13 +0200
Subject: Scene 3D objects throw exception on Android devices
In-Reply-To: <003f01db3771$1022a660$3067f320$@ntlworld.com>
References: <003f01db3771$1022a660$3067f320$@ntlworld.com>
Message-ID: <CA+0ynh8Y1esvjCv+0OSjbEUfHwCzT+Vqig2U7S4o3dPczp9u7w@mail.gmail.com>

This is a question for Gluon, not OpenJFX, as JavaFXPorts and the newer
Gluon client are not part of JavaFX (it's the other way around). I suggest
StackOverflow, they are active there.

I can tell you that JavaFXPorts was EOL years ago. Also that the MBOX might
not have a pipeline with 3D support (in JavaFX it's a ConditionalFeature),
so that's why it might be failing. You might have some luck with setting
the pipeline to the software (SW) pipeline.

On Fri, Nov 15, 2024 at 5:14?PM Ashley Hales <ashley.hales at ntlworld.com>
wrote:

> Hi,
>
> I posted a thread some time ago about Scene 3D objects causing a error when
> they try to create the shader.  At the time I was advised to recompile the
> project using the new Gluon library rather than JavaFXPorts.  I have now
> done this but the result is not compatible with my device.  I have found
> that the Gluon project works fine on a Motorola device running Android 13
> and the JavaFXPorts project works on an old Samsung device running Android
> 4.4.2.  However the Gluon project won't even install on my intended target
> device, which is an MBOX running Android 6.0.1, but the JavaFXPorts project
> installs fine but throws  'java.lang.RuntimeException: Error creating
> shader
> program' on the MBOX.  I have found that the MBOX will run projects not
> containing any 3D objects, for example the two sample projects included in
> the Dalvik SDK - Ensemble8 and HelloAndroid - work fine.  Is there any way
> around this using the JavaFXPorts technology as this has produced the best
> results?  When I try to do a push install to  the MBOX using ADB it gives
> an
> error of 'Failure [INSTALL_FAILED_NO_MATCHING_ABIS]'.  My searches online
> indicate that this may be due to the version of the NDK it was compiled
> with
> but I have found that the project only seems to compile with the Android 21
> NDK.
>
> Thanks for your help,
>
> Ashley
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/717abda1/attachment.htm>

From martin at martinfox.com  Fri Nov 15 21:08:47 2024
From: martin at martinfox.com (Martin Fox)
Date: Fri, 15 Nov 2024 13:08:47 -0800
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
Message-ID: <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>

Michael,

On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window?

(I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.)

In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized.

The way Apple shoe-horned this into the older AppKit is a bit less elegant. There?s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn?t require any alterations to the HeaderBarBase class and it?s too specialized to be added to HeaderBar.

Martin

> On Oct 23, 2024, at 7:19?AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> Hi Michael,
> 
> I like this proposal overall. It provides a commonly-requested feature with a minimal API surface. While I share some of the concerns about implementing it, it is reflective of modern UI design on all of the desktop platforms, so I expect the platform vendors to continue supporting the features this needs to run.
> 
> You had mentioned in your PR the possibility of making this a preview feature, which seems like a good idea. I think it is worth reviving the preview feature proposal, and to consider using it for this feature.
> 
> I have a few overall questions after an initial reading of the JEP. I'll take a closer look and send more specific feedback.
> 
> I presume that the preferred width and height of HeaderBarBase is the width of the window and the height of the system-reserved area for window buttons?
> 
> Are leftSystemInset and rightSystemInset read-only?
> 
> What is the behavior if an application adds more than one HeaderBar? What if they add a HeaderBar that isn't positioned at the top of the Stage? What is the behavior if an app adds a HeaderBar to a DECORATED or UNDECORATED Stage?
> 
> I want to make sure I understand the centering policy: To my eyes, the text field in the macOS example is not horizontally centered in the window. Is this a bug or am I misunderstanding something?
> 
> As Andy already mentioned in the PR, the `EXTENDED` StageStyle should be a ConditionalFeature, similar to TRANSPARENT or UNIFIED. Oh, I see from the PR that you already did this. Can you update the JEP to indicate this?
> 
> And speaking of UNIFIED, it might be worth mentioning the differences between EXTENDED and UNIFIED. Somewhat related to this, we have talked about deprecating (not for removal) UNIFIED and always returning `false` from `ConditionalFeature.isSupported(UNIFIED_WINDOW)`.
> 
> -- Kevin
> 
> On 10/22/2024 4:55 PM, Michael Strau? wrote:
>> Hi everyone,
>> 
>> the discussion in PR #1605 has shown that the proposed feature needs a
>> better presentation in a JEP-like format, so here it is:
>> 
>> https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
> 


From andy.goryachev at oracle.com  Fri Nov 15 21:14:47 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 15 Nov 2024 21:14:47 +0000
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
 <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
Message-ID: <BYAPR10MB3013A0814D6D37297CAF046AE5242@BYAPR10MB3013.namprd10.prod.outlook.com>

Martin:

Are you referring to this (macOS Notes):

[cid:image001.png at 01DB375F.F59057E0]

or something else?

I think the Notes-like UI can be implemented using the proposed HeaderBar (HB), all one needs to do is to bind the width of the left part in the HB to the split pane's divider position, without the need for multiple HB.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martin at martinfox.com>
Date: Friday, November 15, 2024 at 13:09
To: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: JEP: JavaFX controls in the title bar
Michael,

On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window?

(I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.)

In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized.

The way Apple shoe-horned this into the older AppKit is a bit less elegant. There?s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn?t require any alterations to the HeaderBarBase class and it?s too specialized to be added to HeaderBar.

Martin

> On Oct 23, 2024, at 7:19?AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
> Hi Michael,
>
> I like this proposal overall. It provides a commonly-requested feature with a minimal API surface. While I share some of the concerns about implementing it, it is reflective of modern UI design on all of the desktop platforms, so I expect the platform vendors to continue supporting the features this needs to run.
>
> You had mentioned in your PR the possibility of making this a preview feature, which seems like a good idea. I think it is worth reviving the preview feature proposal, and to consider using it for this feature.
>
> I have a few overall questions after an initial reading of the JEP. I'll take a closer look and send more specific feedback.
>
> I presume that the preferred width and height of HeaderBarBase is the width of the window and the height of the system-reserved area for window buttons?
>
> Are leftSystemInset and rightSystemInset read-only?
>
> What is the behavior if an application adds more than one HeaderBar? What if they add a HeaderBar that isn't positioned at the top of the Stage? What is the behavior if an app adds a HeaderBar to a DECORATED or UNDECORATED Stage?
>
> I want to make sure I understand the centering policy: To my eyes, the text field in the macOS example is not horizontally centered in the window. Is this a bug or am I misunderstanding something?
>
> As Andy already mentioned in the PR, the `EXTENDED` StageStyle should be a ConditionalFeature, similar to TRANSPARENT or UNIFIED. Oh, I see from the PR that you already did this. Can you update the JEP to indicate this?
>
> And speaking of UNIFIED, it might be worth mentioning the differences between EXTENDED and UNIFIED. Somewhat related to this, we have talked about deprecating (not for removal) UNIFIED and always returning `false` from `ConditionalFeature.isSupported(UNIFIED_WINDOW)`.
>
> -- Kevin
>
> On 10/22/2024 4:55 PM, Michael Strau? wrote:
>> Hi everyone,
>>
>> the discussion in PR #1605 has shown that the proposed feature needs a
>> better presentation in a JEP-like format, so here it is:
>>
>> https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/b8cbd1d4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 109713 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241115/b8cbd1d4/image001-0001.png>

From michaelstrau2 at gmail.com  Fri Nov 15 22:31:05 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 15 Nov 2024 23:31:05 +0100
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
 <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
Message-ID: <CAJEpuXQ7gBO8+gYupuHTYtOAdGw3xdo89o3gV=4SdG8Mo7vuOA@mail.gmail.com>

I don't really like the idea of supporting multiple HeaderBars. If we
did that, we'd have application developers deviating from the de-facto
implementation requirement that a HeaderBar be placed at the top of
the window, and extend its entire width. If that is not the case, then
leftSystemInset and rightSystemInset don't meanignfully correspond to
the visuals on display. In addition to that, HeaderBarBase negotiates
its height with the platform decorations on macOS, and having more
than one would require us to think about what would happen if they
were different in height.

Why not create a SplitHeaderBar instead? You could have two slots, and
maybe also accept different background paints for the two slots. This
is all possible within the proposed API.



On Fri, Nov 15, 2024 at 10:09?PM Martin Fox <martin at martinfox.com> wrote:
>
> Michael,
>
> On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window?
>
> (I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.)
>
> In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized.
>
> The way Apple shoe-horned this into the older AppKit is a bit less elegant. There?s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn?t require any alterations to the HeaderBarBase class and it?s too specialized to be added to HeaderBar.
>
> Martin

From martin at martinfox.com  Fri Nov 15 23:23:53 2024
From: martin at martinfox.com (Martin Fox)
Date: Fri, 15 Nov 2024 15:23:53 -0800
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <CAJEpuXQ7gBO8+gYupuHTYtOAdGw3xdo89o3gV=4SdG8Mo7vuOA@mail.gmail.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
 <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
 <CAJEpuXQ7gBO8+gYupuHTYtOAdGw3xdo89o3gV=4SdG8Mo7vuOA@mail.gmail.com>
Message-ID: <77384A18-D65F-4F08-8059-D189A516DE4B@martinfox.com>

Perhaps a better app to look at is Mac Weather. The sidebar background color and translucency effects extend all the way to the top of the window. Easy to set up with multiple header bars, considerably more complicated with just one.

If an application developer wants this effect we could either tell them to create multiple HeaderBars and make sure they?re all the same height (which is what they were probably planning to do anyway) OR we could tell them to use a single HeaderBarBase and roll their own solution from scratch including duplicating the SplitPane?s visuals.

> On Nov 15, 2024, at 2:31?PM, Michael Strau? <michaelstrau2 at gmail.com> wrote:
> 
> I don't really like the idea of supporting multiple HeaderBars. If we
> did that, we'd have application developers deviating from the de-facto
> implementation requirement that a HeaderBar be placed at the top of
> the window, and extend its entire width.

The Mac API that implements the split UI automatically creates enough toolbars to span the window, places them in the title bar area, and ensures they?re all the same height. I agree the JavaFX API is more piecemeal which would allow developers to mis-configure the UI. But why would they?

I?m not going to press on this. It just seems that with a little tweaking we could make multiple HeaderBars work and it would provide a cleaner solution going forward.

Martin

From michaelstrau2 at gmail.com  Fri Nov 15 23:26:29 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 16 Nov 2024 00:26:29 +0100
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <BYAPR10MB3013A0814D6D37297CAF046AE5242@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
 <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
 <BYAPR10MB3013A0814D6D37297CAF046AE5242@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXQEKDb3pQetw36eBiBw80tqSVbyNEWYp_jgySFtSf7q8Q@mail.gmail.com>

That's correct. The only thing you can't do out-of-the-box with HeaderBar
is assign different backgrounds to each of the areas (HeaderBar is a
Region, which only has a single background).

Of course, you can place another layout container in one of the areas, and
give the nested container a different background.

But this doesn't really work for the part of the header bar that is
obscured by window controls. For example, let's assume we want to have a
split header bar, but have the background of the left area be different
than the background of the right area. If we simply place another container
in the left area, and change its background, then the new background will
be shifted to the right on macOS (due to the window controls on the left
side of the window), and will not be shown below the window controls.

Application developers could solve this problem in several ways, but here's
one: make the HeaderBar background transparent, and place a background node
with the appropriate width and height _below_ the HeaderBar in the scene
graph.


On Sat, Nov 16, 2024 at 12:07?AM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

>
>
> I think the Notes-like UI can be implemented using the proposed HeaderBar
> (HB), all one needs to do is to bind the width of the left part in the HB
> to the split pane's divider position, without the need for multiple HB.
>
>
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241116/2ddff8b8/attachment.htm>

From andy.goryachev at oracle.com  Fri Nov 15 23:29:24 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 15 Nov 2024 23:29:24 +0000
Subject: JEP: JavaFX controls in the title bar
In-Reply-To: <77384A18-D65F-4F08-8059-D189A516DE4B@martinfox.com>
References: <CAJEpuXTHWpK-e_5wXQXWOE7QyWzhnGz1hQPczsiMoMMZ_CynnQ@mail.gmail.com>
 <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com>
 <C6AC7BB8-785F-44E6-9A09-10E8C939FF51@martinfox.com>
 <CAJEpuXQ7gBO8+gYupuHTYtOAdGw3xdo89o3gV=4SdG8Mo7vuOA@mail.gmail.com>
 <77384A18-D65F-4F08-8059-D189A516DE4B@martinfox.com>
Message-ID: <BYAPR10MB30135485BC90CB702DCC6AE2E5242@BYAPR10MB3013.namprd10.prod.outlook.com>

weather app effect: extend the HeaderBar to the full height, use that as the main container.

multiple HeaderBars is something we probably should avoid.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martin at martinfox.com>
Date: Friday, November 15, 2024 at 15:24
To: Michael Strau? <michaelstrau2 at gmail.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: JEP: JavaFX controls in the title bar
Perhaps a better app to look at is Mac Weather. The sidebar background color and translucency effects extend all the way to the top of the window. Easy to set up with multiple header bars, considerably more complicated with just one.

If an application developer wants this effect we could either tell them to create multiple HeaderBars and make sure they?re all the same height (which is what they were probably planning to do anyway) OR we could tell them to use a single HeaderBarBase and roll their own solution from scratch including duplicating the SplitPane?s visuals.

> On Nov 15, 2024, at 2:31?PM, Michael Strau? <michaelstrau2 at gmail.com> wrote:
>
> I don't really like the idea of supporting multiple HeaderBars. If we
> did that, we'd have application developers deviating from the de-facto
> implementation requirement that a HeaderBar be placed at the top of
> the window, and extend its entire width.

The Mac API that implements the split UI automatically creates enough toolbars to span the window, places them in the title bar area, and ensures they?re all the same height. I agree the JavaFX API is more piecemeal which would allow developers to mis-configure the UI. But why would they?

I?m not going to press on this. It just seems that with a little tweaking we could make multiple HeaderBars work and it would provide a cleaner solution going forward.

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

From mhanl at openjdk.org  Sat Nov 16 00:24:56 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 16 Nov 2024 00:24:56 GMT
Subject: RFR: 8290037: Bindings should clean up after themselves when their
 weak listeners go out of scope [v2]
In-Reply-To: <eibQwIJilqajTpQuWDQtMu-lf35o6oXxC1HaCrxe_iY=.62d6e7c9-c65b-4a35-a1f8-149ca0994f7e@github.com>
References: <exeM5CpdMHOJ4poZr2nW5CULN9QJvCfbwxIY8MxIuBA=.87c2b4fc-55f6-4f1c-b2b0-bda9e6ec72a8@github.com>
 <eibQwIJilqajTpQuWDQtMu-lf35o6oXxC1HaCrxe_iY=.62d6e7c9-c65b-4a35-a1f8-149ca0994f7e@github.com>
Message-ID: <7Ys2Gq-_RpUGE3fqCL7c9SD6T_27dOXolxWGkCoww48=.d62af073-190d-47fb-9870-282274176f9f@github.com>

On Thu, 14 Jul 2022 19:48:04 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This is an initial (incomplete) implementation of 8290037 for evaluation.
>> 
>> If the approach is agreed, I will modify the rest of the `*PropertyBase` classes which use weak listeners, and add some tests.
>> 
>> I didn't use `Cleaner` because cleaning up a listener may block.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made accidental public field private

Does this address the problem that Bindings seem to not clean up properly, e.g. something a Binding like this:
`xyz.bind(col.visibleProperty().and(col.resizableProperty())`
seems to not properly cleanup after calling:
`xyz.undbind()`
as when checking the listener in the `ExpressionHelper`, the `col.visibleProperty()` Binding is still in there (`xyz` binding is of course cleared, but this remains).

This is something I discovered some days ago and was not aware that this is the case, although not sure if I miss something here.

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

PR Comment: https://git.openjdk.org/jfx/pull/827#issuecomment-2480199574

From mhanl at openjdk.org  Sat Nov 16 01:07:07 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 16 Nov 2024 01:07:07 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton
Message-ID: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>

There are multiple issues in the `TableMenu` logic that result in a memory leak.

The following problems are now fixed with this PR:
- The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
   - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
- The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
  - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column

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

Commit messages:
 - 8341687: Memory leak in TableView after interacting with TableMenuButton

Changes: https://git.openjdk.org/jfx/pull/1640/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341687
  Stats: 177 lines in 3 files changed: 159 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1640.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1640/head:pull/1640

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

From kcr at openjdk.org  Sat Nov 16 14:29:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 14:29:14 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
Message-ID: <Y_nkH4L1GBrNYhS_S__knUP2IO3LmIqzDScVYFI_9O0=.5905160b-2c49-4a81-b7f8-baca1ddd6002@github.com>

On Fri, 15 Nov 2024 02:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - test cleanup
>  - add missing copyright header

tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 60:

> 58:         Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470
> 59:         Assumptions.assumeTrue(Util.isOnWayland());
> 60:         robot = new Robot();

This initializes the AWT toolkit before the FX toolkit. Have you also tested it the other way around? I'm not sure it matters on Linux (unlike macOS where it does matter), so maybe unimportant.

tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 72:

> 70:     private static void awtPixelOnFxThread() throws InterruptedException {
> 71:         System.out.println("awtPixelOnFxThread");
> 72:         initFX();

Have you considered moving the `initFX()` call to the `init` method (after the call to AWT robot) so you only need it in one place?

tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 143:

> 141:                 DELAY_BEFORE_SESSION_CLOSE + 25
> 142:         ).forEach(delay -> {
> 143:             System.out.println("Testing with delay: " + delay);

You might consider making this a parameterized test with this list of delays as the parameters, if it isn't too hard.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1844245065
PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1844245832
PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1844265977

From kcr at openjdk.org  Sat Nov 16 14:29:56 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 14:29:56 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v3]
In-Reply-To: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
Message-ID: <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>

> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
> 
> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
> 
> ### Notes to reviewers
> 
> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  review feedback

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1638/files
  - new: https://git.openjdk.org/jfx/pull/1638/files/f01faa1e..64556c26

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

  Stats: 24 lines in 2 files changed: 1 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1638.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1638/head:pull/1638

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

From kcr at openjdk.org  Sat Nov 16 15:16:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 15:16:11 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
Message-ID: <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>

On Fri, 15 Nov 2024 05:48:15 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte 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 'master' into exp-suffix
>  - 8343196: Add build property to identify experimental builds of JavaFX

Looks good. I left a couple comments and will reapprove if you decide to make the changes.

build.gradle line 705:

> 703:     } else {
> 704:         relSuffix = jfxExperimentalReleaseSuffix != "" ?
> 705:                         jfxExperimentalReleaseSuffix : jfxReleaseSuffix;

One thought I had: we might also want to set `relOpt = "-${buildTimestamp}"` here like we do for internal builds so we always see a time stamp for experimental builds. What do you think?

build.properties line 42:

> 40: 
> 41: # The experimental release suffix is set only in jfx-sandbox repository
> 42: # for a speficic branch. When this property is set it overrides

Do you want to say something about it needing to start with a `-`? Or do you think the example of `-ea` above will be clear enough?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1637#pullrequestreview-2440546348
PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1844995084
PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1844995524

From jvos at openjdk.org  Sat Nov 16 15:40:11 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 16 Nov 2024 15:40:11 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
Message-ID: <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>

On Fri, 15 Nov 2024 05:48:15 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte 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 'master' into exp-suffix
>  - 8343196: Add build property to identify experimental builds of JavaFX

I might be confused, but wasn't the idea to use a new property (e.g. jfx.feature.variant) instead of overloading the existing jfx.release.suffix?

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2480619738

From kcr at openjdk.org  Sat Nov 16 16:20:43 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 16:20:43 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>
Message-ID: <LQynwCxJ5lcHZEk9aWSLh8VKWofKLDsdjB0fFWpkThA=.9b135100-8f23-4a35-9403-dc0ac38672a1@github.com>

On Sat, 16 Nov 2024 15:37:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> I might be confused, but wasn't the idea to use a new property (e.g. jfx.feature.variant) instead of overloading the existing jfx.release.suffix?

This PR does add a new property in `build.properties`,`jfx.experimental.release.suffix`, and does not require modifying `jfx.release.suffix`. For example, in the "metal" branch of the jfx-sandbox, we would define this as:


jfx.experimental.release.suffix=-metal

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2480636641

From kcr at openjdk.org  Sat Nov 16 16:42:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 16:42:53 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
Message-ID: <O9XAKaVBf8MLkSgzEZxjQSxpMz67S2cfIDwgKD6lgxw=.d39de4e2-713e-487c-beee-09734940a61d@github.com>

On Fri, 15 Nov 2024 02:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - test cleanup
>  - add missing copyright header

I tested this with and without the AWT patch in openjdk/jdk#22131 and all looks good. I left a couple minor comments on the test earlier.

I can't reproduce the crash without this fix on my system, but since it does happen on some systems, it does need to be fixed.

We should backport this to jfx23u once integrated.

@lukostyra Can you be the second reviewer?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1639#pullrequestreview-2440768655
PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2480647453

From kcr at openjdk.org  Sat Nov 16 16:52:43 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 16:52:43 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
Message-ID: <qarc81Do_wQVijSPuhtPJQWWcNUo4gh4VknxJZet0Ng=.6684329a-dc1c-4dd3-b32d-e447d36fbb06@github.com>

On Fri, 15 Nov 2024 02:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - test cleanup
>  - add missing copyright header

tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 58:

> 56:     @BeforeAll
> 57:     public static void init() throws Exception {
> 58:         Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470

Once the AWT fix is in a promoted build of JDK 24, this can be replaced (here and in the other two test classes that are excluded on Wayland) with:


    assumeTrue(Runtime.version().feature() >= 24);


I added this as a comment in the bug report for JDK-8335470 as well.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1845075239

From kcr at openjdk.org  Sat Nov 16 17:29:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 17:29:47 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <BkilYQV6-7OADPy52Cy5MXbabTSgl8y55r0UAgDcHms=.8b22a82c-9a78-4580-b4a8-2e492fce1131@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
 <BkilYQV6-7OADPy52Cy5MXbabTSgl8y55r0UAgDcHms=.8b22a82c-9a78-4580-b4a8-2e492fce1131@github.com>
Message-ID: <3s8R5xERaNeLyYhShtze-NLpfQXe84-Cp4N9l7B73Qg=.cd28b93c-1b64-4a60-bb31-6d9414fd8a67@github.com>

On Thu, 14 Nov 2024 23:15:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional comments
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 375:
> 
>> 373:     // than a HashSet of WeakReferences so that the entries are automatically
>> 374:     // removed after the listener is garbage collected.
>> 375:     private final Map<TKPulseListener,Object> stagePulseListeners = new WeakHashMap<>();
> 
> I recommend using a set instead of a map, which is a bit less confusing:
> 
> private final Set<TKPulseListener> stagePulseListeners = Collections.newSetFromMap(new WeakHashMap<>())

Good suggestion. I made this change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1844984078

From kcr at openjdk.org  Sat Nov 16 17:29:48 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 17:29:48 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v2]
In-Reply-To: <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <V03qa7mVhcveQXOEjrjMuzEaSYw0lKlvz9A7pJk7CYc=.64751454-6b06-490c-b4b4-910c3633b33e@github.com>
 <E-Zk-ZqpJ5zb_j56tYUDB8QsSAorsxbhrcrqhOffJF8=.c03ee52c-800a-4519-8ff3-8b6bad2bb068@github.com>
Message-ID: <-m2tR-jCAUzWJ4neBUKEMGRx9p0UMcIYS31YZyP3y7A=.ad4b7ef2-c876-4a64-802f-1ffcf1e02fa3@github.com>

On Thu, 14 Nov 2024 23:33:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional comments
>
> modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 45:
> 
>> 43:     // We do this, rather than removing the parameter, in order to keep the
>> 44:     // native WebKit code the same across different release families.
>> 45:     private static final Object dummyAcc = new Object();
> 
> very minor: all uppercase name

done (in many cases I don't think this convention is needed, but it seems good here)

> modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 120:
> 
>> 118:     public void setSlot(int index, Object value) throws JSException {
>> 119:         Invoker.getInvoker().checkEventThread();
>> 120:         setSlotImpl(peer, peer_type, index, value,dummyAcc);
> 
> missing space after `,`

fixed

> modules/javafx.web/src/main/java/com/sun/webkit/dom/JSObject.java line 129:
> 
>> 127:     public Object call(String methodName, Object... args) throws JSException {
>> 128:         Invoker.getInvoker().checkEventThread();
>> 129:         return callImpl(peer, peer_type, methodName, args,dummyAcc);
> 
> missing space after `,`

fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1844986477
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1844983781
PR Review Comment: https://git.openjdk.org/jfx/pull/1638#discussion_r1844983815

From jvos at openjdk.org  Sat Nov 16 18:29:47 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 16 Nov 2024 18:29:47 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
Message-ID: <8khEJKFeeEi28yd6AUT1FxOpF_gRpn28s5Vxo_c7ddk=.10af52f5-d4fd-41d8-8b5c-a1c02c0d1210@github.com>

On Sat, 16 Nov 2024 15:09:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte 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 'master' into exp-suffix
>>  - 8343196: Add build property to identify experimental builds of JavaFX
>
> build.gradle line 705:
> 
>> 703:     } else {
>> 704:         relSuffix = jfxExperimentalReleaseSuffix != "" ?
>> 705:                         jfxExperimentalReleaseSuffix : jfxReleaseSuffix;
> 
> One thought I had: we might also want to set `relOpt = "-${buildTimestamp}"` here like we do for internal builds so we always see a time stamp for experimental builds. What do you think?

I agree with that. It is often useful to have timestamp info in the builds during development.
I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable. I'm not insisting on this for this PR, but I think it is worth thinking about this whenever changes to build.gradle are made.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1845179006

From jvos at openjdk.org  Sat Nov 16 18:34:51 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 16 Nov 2024 18:34:51 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <LQynwCxJ5lcHZEk9aWSLh8VKWofKLDsdjB0fFWpkThA=.9b135100-8f23-4a35-9403-dc0ac38672a1@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>
 <LQynwCxJ5lcHZEk9aWSLh8VKWofKLDsdjB0fFWpkThA=.9b135100-8f23-4a35-9403-dc0ac38672a1@github.com>
Message-ID: <HRRsibVhYo_KYqO5S2ykT9ZwQ5uSJ_gSQIdDrfunw2A=.3653fb98-a184-4d74-9fa5-387c440e86f3@github.com>

On Sat, 16 Nov 2024 16:16:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > I might be confused, but wasn't the idea to use a new property (e.g. jfx.feature.variant) instead of overloading the existing jfx.release.suffix?
> 
> This PR does add a new property in `build.properties`,`jfx.experimental.release.suffix`, and does not require modifying `jfx.release.suffix`. For example, in the "metal" branch of the jfx-sandbox, we would define this as:
> 
> ```
> jfx.experimental.release.suffix=-metal
> ```

My apologies, I misread the proposed code. 
It is a bit confusing to have "jfx.release.suffix" and "jfx.experimental.release.suffix" where the former refers to an artifact property and the latter refers to a major feature/variant/... like metal. But then, consistent naming is always difficult so I'm ok with the proposed suggestion.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2480728513

From mstrauss at openjdk.org  Sat Nov 16 19:45:10 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 16 Nov 2024 19:45:10 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v3]
In-Reply-To: <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>
Message-ID: <SqkrwqWHtLJAcMCg24XW-_KVbFjFh51Iu39EPY45ibw=.05893393-b346-4826-a070-e21f6d7441ae@github.com>

On Sat, 16 Nov 2024 14:29:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
>> 
>> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
>> 
>> ### Notes to reviewers
>> 
>> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
>> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Marked as reviewed by mstrauss (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1638#pullrequestreview-2440795446

From nlisker at openjdk.org  Sat Nov 16 19:45:48 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 16 Nov 2024 19:45:48 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <8khEJKFeeEi28yd6AUT1FxOpF_gRpn28s5Vxo_c7ddk=.10af52f5-d4fd-41d8-8b5c-a1c02c0d1210@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
 <8khEJKFeeEi28yd6AUT1FxOpF_gRpn28s5Vxo_c7ddk=.10af52f5-d4fd-41d8-8b5c-a1c02c0d1210@github.com>
Message-ID: <pLPXk2q6NFd17ER0v79cZNBcRcv8xKPhjaGmExTdgYs=.9e5a3b63-a4e3-4453-97e1-1e6ba0f74499@github.com>

On Sat, 16 Nov 2024 18:27:02 GMT, Johan Vos <jvos at openjdk.org> wrote:

> I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable.

Also at the risk of sounding like a broken record, https://github.com/openjdk/jfx/pull/1232 has been waiting to start this process for a while now and it's stuck waiting for explanations on how publishing works, something only Oracle and Gluon do. If someone can help Jendrik Johannes there then the ball will get rolling. I tried to split the big build file into separate files for each module, but it's entangled with the code in that PR. Completing that PR might also remove the need for the JavaFX plugin.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1845216786

From azvegint at openjdk.org  Sat Nov 16 20:19:06 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 16 Nov 2024 20:19:06 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v3]
In-Reply-To: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
Message-ID: <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>

> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
> 
> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
> 
> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
> 
> ---- 
> 
> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
> This is to reduce overhead in case of frequent consecutive screen captures.
> 
> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
> 
> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
> 
> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
> 
> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
> 
> ----
> 
> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
> But if the JDK and JavaFX have the fixes, everything works fine.
> Testing in other different scenarios also looks good.

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - formatting
 - ParameterizedTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1639/files
  - new: https://git.openjdk.org/jfx/pull/1639/files/eb273f0c..a2319785

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

  Stats: 26 lines in 1 file changed: 2 ins; 8 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1639.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1639/head:pull/1639

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

From azvegint at openjdk.org  Sat Nov 16 20:19:07 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 16 Nov 2024 20:19:07 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <Y_nkH4L1GBrNYhS_S__knUP2IO3LmIqzDScVYFI_9O0=.5905160b-2c49-4a81-b7f8-baca1ddd6002@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
 <Y_nkH4L1GBrNYhS_S__knUP2IO3LmIqzDScVYFI_9O0=.5905160b-2c49-4a81-b7f8-baca1ddd6002@github.com>
Message-ID: <osvTGaWJY3oXaeZfWT0j64NFSqGSNnVnPKrl8LhN8Lo=.935b729f-936e-4ec6-863e-7934e5e0cdf2@github.com>

On Fri, 15 Nov 2024 17:47:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - test cleanup
>>  - add missing copyright header
>
> tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 60:
> 
>> 58:         Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470
>> 59:         Assumptions.assumeTrue(Util.isOnWayland());
>> 60:         robot = new Robot();
> 
> This initializes the AWT toolkit before the FX toolkit. Have you also tested it the other way around? I'm not sure it matters on Linux (unlike macOS where it does matter), so maybe unimportant.

Yes, and I see no difference in behavior.

> tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 72:
> 
>> 70:     private static void awtPixelOnFxThread() throws InterruptedException {
>> 71:         System.out.println("awtPixelOnFxThread");
>> 72:         initFX();
> 
> Have you considered moving the `initFX()` call to the `init` method (after the call to AWT robot) so you only need it in one place?

It is intentionally kept out of the `init()` method to be able to test the

> 1. If there is no GTK main loop running
Example: just a JDK only application.
In this case we call g_main_context_iteration(NULL, TRUE) as before (when [gtk_main_level() == 0](https://docs.gtk.org/gtk3/func.main_level.html)).

like


awtPixel();
robot.delay(DELAY_WAIT_FOR_SESSION_TO_CLOSE);

initFX();
robot.delay(500);
awtPixel();

> tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 143:
> 
>> 141:                 DELAY_BEFORE_SESSION_CLOSE + 25
>> 142:         ).forEach(delay -> {
>> 143:             System.out.println("Testing with delay: " + delay);
> 
> You might consider making this a parameterized test with this list of delays as the parameters, if it isn't too hard.

Sure, it is not hard at all. Updated.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1845231679
PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1845232139
PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1845232430

From azvegint at openjdk.org  Sat Nov 16 20:41:10 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 16 Nov 2024 20:41:10 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <O9XAKaVBf8MLkSgzEZxjQSxpMz67S2cfIDwgKD6lgxw=.d39de4e2-713e-487c-beee-09734940a61d@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
 <O9XAKaVBf8MLkSgzEZxjQSxpMz67S2cfIDwgKD6lgxw=.d39de4e2-713e-487c-beee-09734940a61d@github.com>
Message-ID: <aKi8rsplsjvZDNzDbaNWOA9DwwibfnPhSvGziLMZGAg=.ae686ec2-0a01-4168-b20a-e17d76ef4856@github.com>

On Sat, 16 Nov 2024 16:39:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I can't reproduce the crash without this fix on my system, but since it does happen on some systems, it does need to be fixed.

Just to be on the same page, it still crashes for me (at least on Ubuntu 22.04) as expected for the following scenarios:

1. Do one of the following 
    1. Build the JDK's [/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) full changeset + take some JFX build without this PR(aka any random JFX build).
    2. Build the JDK with only an [a. part](https://github.com/openjdk/jdk/pull/22131#a-part) + JFX build with this PR
2. Comment out the `Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470` line in `LinuxScreencastHangCrashTest` and run the test on Wayland.
3. observe that the `LinuxScreencastHangCrashTest#testHang` fails.

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2480803092

From kcr at openjdk.org  Sat Nov 16 22:34:51 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 22:34:51 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <HRRsibVhYo_KYqO5S2ykT9ZwQ5uSJ_gSQIdDrfunw2A=.3653fb98-a184-4d74-9fa5-387c440e86f3@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>
 <LQynwCxJ5lcHZEk9aWSLh8VKWofKLDsdjB0fFWpkThA=.9b135100-8f23-4a35-9403-dc0ac38672a1@github.com>
 <HRRsibVhYo_KYqO5S2ykT9ZwQ5uSJ_gSQIdDrfunw2A=.3653fb98-a184-4d74-9fa5-387c440e86f3@github.com>
Message-ID: <Wnn43qfJ2QxYbuY2MMyiIe0HXPjpjKRY65NxjPDuv9I=.e2afdce8-0f00-4df8-af96-cda6a869ec0d@github.com>

On Sat, 16 Nov 2024 18:32:10 GMT, Johan Vos <jvos at openjdk.org> wrote:

> It is a bit confusing to have "jfx.release.suffix" and "jfx.experimental.release.suffix" where the former refers to an artifact property and the latter refers to a major feature/variant/... like metal. 

I think you have a good point. Maybe we should drop the '.suffix' in the name of this property (in which case, it wouldn't have a `-` so the logic in `build.gradle` would add the `-` when needed). It would probably be easier to document it as well.

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2480833449

From kcr at openjdk.org  Sat Nov 16 22:38:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 16 Nov 2024 22:38:52 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
Message-ID: <CTGRKKa4sGrJ5RBeFk78Rytb5qjar5GVvsDlNk09Tq0=.82cb6d2b-18ab-4d5a-8e02-ed13b29fefbe@github.com>

On Fri, 15 Nov 2024 05:48:15 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte 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 'master' into exp-suffix
>  - 8343196: Add build property to identify experimental builds of JavaFX

If we do this, then here are some possible names:

* jfx.experimental.release
* jfx.experimental.release.name
* jfx.variant.release
* jfx.variant.release.name
* jfx.variant
* jfx.feature.variant

Thoughts?

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2480834269

From jvos at openjdk.org  Sun Nov 17 09:02:52 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 17 Nov 2024 09:02:52 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <Wnn43qfJ2QxYbuY2MMyiIe0HXPjpjKRY65NxjPDuv9I=.e2afdce8-0f00-4df8-af96-cda6a869ec0d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <7xh0llLMgYTf_UVJOpxt_KKgEjDFg-sQuL269ePFCoY=.2a69e2b1-e252-4077-8d2a-68ff35736ff9@github.com>
 <LQynwCxJ5lcHZEk9aWSLh8VKWofKLDsdjB0fFWpkThA=.9b135100-8f23-4a35-9403-dc0ac38672a1@github.com>
 <HRRsibVhYo_KYqO5S2ykT9ZwQ5uSJ_gSQIdDrfunw2A=.3653fb98-a184-4d74-9fa5-387c440e86f3@github.com>
 <Wnn43qfJ2QxYbuY2MMyiIe0HXPjpjKRY65NxjPDuv9I=.e2afdce8-0f00-4df8-af96-cda6a869ec0d@github.com>
Message-ID: <kt8cSonYBhZfL8Wr8ERR1LLBlFtac44Hjf41_Judsss=.b517ac66-40e5-40fa-8c9c-c14f81882f48@github.com>

On Sat, 16 Nov 2024 22:32:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > It is a bit confusing to have "jfx.release.suffix" and "jfx.experimental.release.suffix" where the former refers to an artifact property and the latter refers to a major feature/variant/... like metal.
> 
> I think you have a good point. Maybe we should drop the '.suffix' in the name of this property (in which case, it wouldn't have a `-` so the logic in `build.gradle` would add the `-` when needed). It would probably be easier to document it as well.
> 
> What do you think?

That makes sense (removing the word ".suffix")

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2481052538

From jvos at openjdk.org  Sun Nov 17 09:05:49 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 17 Nov 2024 09:05:49 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <CTGRKKa4sGrJ5RBeFk78Rytb5qjar5GVvsDlNk09Tq0=.82cb6d2b-18ab-4d5a-8e02-ed13b29fefbe@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <CTGRKKa4sGrJ5RBeFk78Rytb5qjar5GVvsDlNk09Tq0=.82cb6d2b-18ab-4d5a-8e02-ed13b29fefbe@github.com>
Message-ID: <YVGz5AIXqmDZjjBBstSjoMYGAWijHbRA2QE2vSUuIAM=.1baad08b-2e46-4420-a9ff-405228d5c83e@github.com>

On Sat, 16 Nov 2024 22:36:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> If we do this, then here are some possible names:
> 
> * jfx.experimental.release
> * jfx.experimental.release.name
> * jfx.variant.release
> * jfx.variant.release.name
> * jfx.variant
> * jfx.feature.variant
> 
> Thoughts?

I don't have objections against any of those.
If I have to vote, my vote would go to "jfx.feature.name" (which is not in the list ;) ) because I associate variant rather with a single option from a wider set (e.g. prism variants are sw, es2,,...)
But I am more than happy with any name on this list.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2481057217

From jvos at openjdk.org  Sun Nov 17 09:09:15 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 17 Nov 2024 09:09:15 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <pLPXk2q6NFd17ER0v79cZNBcRcv8xKPhjaGmExTdgYs=.9e5a3b63-a4e3-4453-97e1-1e6ba0f74499@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
 <8khEJKFeeEi28yd6AUT1FxOpF_gRpn28s5Vxo_c7ddk=.10af52f5-d4fd-41d8-8b5c-a1c02c0d1210@github.com>
 <pLPXk2q6NFd17ER0v79cZNBcRcv8xKPhjaGmExTdgYs=.9e5a3b63-a4e3-4453-97e1-1e6ba0f74499@github.com>
Message-ID: <Yb6u3Nc8yxPrIm0QPjAF3eCmYzjn2x43dgz93px2Awo=.128a94a9-16dc-4fe4-b1ab-524cd3b820c0@github.com>

On Sat, 16 Nov 2024 19:43:07 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> I agree with that. It is often useful to have timestamp info in the builds during development.
>> I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable. I'm not insisting on this for this PR, but I think it is worth thinking about this whenever changes to build.gradle are made.
>
>> I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable.
> 
> Also at the risk of sounding like a broken record, https://github.com/openjdk/jfx/pull/1232 has been waiting to start this process for a while now and it's stuck waiting for explanations on how publishing works, something only Oracle and Gluon do. If someone can help Jendrik Johannes there then the ball will get rolling. I tried to split the big build file into separate files for each module, but it's entangled with the code in that PR. Completing that PR might also remove the need for the JavaFX plugin.

> > I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable.
> 
> Also at the risk of sounding like a broken record, #1232 has been waiting to start this process for a while now and it's stuck waiting for explanations on how publishing works, something only Oracle and Gluon do. If someone can help Jendrik Johannes there then the ball will get rolling. I tried to split the big build file into separate files for each module, but it's entangled with the code in that PR. Completing that PR might also remove the need for the JavaFX plugin.

Fair remark. I just commented on the PR.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1845340131

From thiago.sayao at gmail.com  Sun Nov 17 14:29:36 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 17 Nov 2024 11:29:36 -0300
Subject: jextract on JavaFx
Message-ID: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>

Hi,

Are there any plans to make a default way to use jextract (or any other way
to use ffm) on the gradle build system?

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

From nlisker at openjdk.org  Sun Nov 17 15:33:50 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 17 Nov 2024 15:33:50 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
Message-ID: <q-XpKexxVhwn5k0HPvgOhXzGv52TR8KwMgqJSkCWchM=.28a13d67-b106-45c2-9262-278c08e64f2a@github.com>

On Fri, 15 Nov 2024 05:48:15 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte 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 'master' into exp-suffix
>  - 8343196: Add build property to identify experimental builds of JavaFX

Variants are also something [Gradle](https://docs.gradle.org/current/userguide/variant_model.html#sec:abm-configuration-attributes) uses to select one of several components, so I suggest to avoid this overload. JavaFX should use Gradle variants for selection of operating systems.

I would have went with `jfx.experimental.name` :) because the sandbox has experimental features, as opposed to other features that are directly integrated into the main stream.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2481317205

From nlisker at gmail.com  Sun Nov 17 16:17:52 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 17 Nov 2024 18:17:52 +0200
Subject: jextract on JavaFx
In-Reply-To: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
References: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
Message-ID: <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>

jextract is something you run once to produce the FFM bindings that you
then add to your code base, there's no need to make it part of the build
(although I guess you can). I would think that If you're creating a PR that
needs FFM, use jextract to produce the java files and submit them as part
of the PR. Not sure what package arrangement is suitable.

On Sun, Nov 17, 2024 at 4:29?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> Hi,
>
> Are there any plans to make a default way to use jextract (or any other
> way to use ffm) on the gradle build system?
>
> -- Thiago
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241117/76d24fec/attachment.htm>

From thiago.sayao at gmail.com  Sun Nov 17 16:43:48 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 17 Nov 2024 13:43:48 -0300
Subject: jextract on JavaFx
In-Reply-To: <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>
References: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
 <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>
Message-ID: <CAAP_wumB7r01UbV0bHOkdhuUgxoa_LSkJFUgN-mfn-=E+DX8rg@mail.gmail.com>

I was thinking about including a generation task as part of the build.
But you're right, I can make a simpler task that generates it by running
jextract only on demand rather than being part of the build.








Em dom., 17 de nov. de 2024 ?s 13:18, Nir Lisker <nlisker at gmail.com>
escreveu:

> jextract is something you run once to produce the FFM bindings that you
> then add to your code base, there's no need to make it part of the build
> (although I guess you can). I would think that If you're creating a PR that
> needs FFM, use jextract to produce the java files and submit them as part
> of the PR. Not sure what package arrangement is suitable.
>
> On Sun, Nov 17, 2024 at 4:29?PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> Hi,
>>
>> Are there any plans to make a default way to use jextract (or any other
>> way to use ffm) on the gradle build system?
>>
>> -- Thiago
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241117/6e4f7e1e/attachment.htm>

From mfox at openjdk.org  Sun Nov 17 20:22:29 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sun, 17 Nov 2024 20:22:29 GMT
Subject: RFR: 8338000: Remove GlassFullscreenWindow
Message-ID: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>

The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into macfscleanup
 - Removed old fullscreen handling cruft.

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

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

From nlisker at openjdk.org  Sun Nov 17 21:42:22 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 17 Nov 2024 21:42:22 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
Message-ID: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>

A batch of typo and grammar fixes that were found by the spellchecker.

Integration can wait until RDP 1/2.

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

Commit messages:
 - More corrections
 - Batch typo fixes
 - Fix mistakes in OpenJFX docs

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

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

From nlisker at gmail.com  Sun Nov 17 22:22:38 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 18 Nov 2024 00:22:38 +0200
Subject: jextract on JavaFx
In-Reply-To: <CAAP_wumB7r01UbV0bHOkdhuUgxoa_LSkJFUgN-mfn-=E+DX8rg@mail.gmail.com>
References: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
 <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>
 <CAAP_wumB7r01UbV0bHOkdhuUgxoa_LSkJFUgN-mfn-=E+DX8rg@mail.gmail.com>
Message-ID: <CA+0ynh9sXvrdw5XBZ8f87i72=6n+dCe7p06m7rmV9X0RjSWeYw@mail.gmail.com>

The question is: what are you binding to? If it's a library on the OS that
gets updated from time to time and JavaFX relies on it being there (not
bundled), then the generated bindings in a task could change and break
compilation if the Java code wasn't changed. If it's a library created by
JavaFX, like the bindings to graphic pipelines, then you won't want to
re-run the task until you actually change the native side yourself.

On Sun, Nov 17, 2024 at 6:44?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> I was thinking about including a generation task as part of the build.
> But you're right, I can make a simpler task that generates it by running
> jextract only on demand rather than being part of the build.
>
>
>
>
>
>
>
>
> Em dom., 17 de nov. de 2024 ?s 13:18, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> jextract is something you run once to produce the FFM bindings that you
>> then add to your code base, there's no need to make it part of the build
>> (although I guess you can). I would think that If you're creating a PR that
>> needs FFM, use jextract to produce the java files and submit them as part
>> of the PR. Not sure what package arrangement is suitable.
>>
>> On Sun, Nov 17, 2024 at 4:29?PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Are there any plans to make a default way to use jextract (or any other
>>> way to use ffm) on the gradle build system?
>>>
>>> -- Thiago
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241118/809633f4/attachment.htm>

From thiago.sayao at gmail.com  Sun Nov 17 23:49:37 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 17 Nov 2024 20:49:37 -0300
Subject: jextract on JavaFx
In-Reply-To: <CA+0ynh9sXvrdw5XBZ8f87i72=6n+dCe7p06m7rmV9X0RjSWeYw@mail.gmail.com>
References: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
 <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>
 <CAAP_wumB7r01UbV0bHOkdhuUgxoa_LSkJFUgN-mfn-=E+DX8rg@mail.gmail.com>
 <CA+0ynh9sXvrdw5XBZ8f87i72=6n+dCe7p06m7rmV9X0RjSWeYw@mail.gmail.com>
Message-ID: <CAAP_wuk9aXhdSeiMyJvCyRezANHKbaG_bqrYS8iTdDLOOp+q8g@mail.gmail.com>

I would have a system lib that would be compatible forever (theoretically)
and some C code,
but I just want to bind specific functions, structs, typedefs, vars and
constants (it's a big jextract command)

So in the need of new functions from C to java, some might need to
re-generate the bindings and it
would be useful to have a gradle task for that, or any other way of
re-generating it.

Less important, but I need clearance to push it to javafx sandbox if I
touch any new API, but I think (but not sure) it would be easier (to get
clearance) if
I don't include the actual binding to the API, but the binding generation
(so the user of the branch generates it on his own machine).



Em dom., 17 de nov. de 2024 ?s 19:23, Nir Lisker <nlisker at gmail.com>
escreveu:

> The question is: what are you binding to? If it's a library on the OS that
> gets updated from time to time and JavaFX relies on it being there (not
> bundled), then the generated bindings in a task could change and break
> compilation if the Java code wasn't changed. If it's a library created by
> JavaFX, like the bindings to graphic pipelines, then you won't want to
> re-run the task until you actually change the native side yourself.
>
> On Sun, Nov 17, 2024 at 6:44?PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> I was thinking about including a generation task as part of the build.
>> But you're right, I can make a simpler task that generates it by running
>> jextract only on demand rather than being part of the build.
>>
>>
>>
>>
>>
>>
>>
>>
>> Em dom., 17 de nov. de 2024 ?s 13:18, Nir Lisker <nlisker at gmail.com>
>> escreveu:
>>
>>> jextract is something you run once to produce the FFM bindings that you
>>> then add to your code base, there's no need to make it part of the build
>>> (although I guess you can). I would think that If you're creating a PR that
>>> needs FFM, use jextract to produce the java files and submit them as part
>>> of the PR. Not sure what package arrangement is suitable.
>>>
>>> On Sun, Nov 17, 2024 at 4:29?PM Thiago Milczarek Say?o <
>>> thiago.sayao at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Are there any plans to make a default way to use jextract (or any other
>>>> way to use ffm) on the gradle build system?
>>>>
>>>> -- Thiago
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241117/7e573c2e/attachment-0001.htm>

From johan.vos at gluonhq.com  Mon Nov 18 07:55:53 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 18 Nov 2024 08:55:53 +0100
Subject: jextract on JavaFx
In-Reply-To: <CAAP_wuk9aXhdSeiMyJvCyRezANHKbaG_bqrYS8iTdDLOOp+q8g@mail.gmail.com>
References: <CAAP_wu=iTaUuBjYpHi1WJ7KkCMM394o=-Fizdkhs_JostRKiFA@mail.gmail.com>
 <CA+0ynh_i+Ww5DRdFhmcMe6eSkopuB_V2bgZvNXDAg4xhbtZVsg@mail.gmail.com>
 <CAAP_wumB7r01UbV0bHOkdhuUgxoa_LSkJFUgN-mfn-=E+DX8rg@mail.gmail.com>
 <CA+0ynh9sXvrdw5XBZ8f87i72=6n+dCe7p06m7rmV9X0RjSWeYw@mail.gmail.com>
 <CAAP_wuk9aXhdSeiMyJvCyRezANHKbaG_bqrYS8iTdDLOOp+q8g@mail.gmail.com>
Message-ID: <CABxFH2Hfs7QX0dsDmExS2gyoOL4y83LiwhtDTyG5W1wgevEr9Q@mail.gmail.com>

The latter (have the bindings generated at build time) is more in line with
other parts of OpenJFX (e.g. decora).
Also, the generated files can be large, and depend on what version of
jextract one is using.
I think it's better not to have them in the src section of the code, but to
generate them at runtime.

- Johan

On Mon, Nov 18, 2024 at 12:50?AM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> I would have a system lib that would be compatible forever (theoretically)
> and some C code,
> but I just want to bind specific functions, structs, typedefs, vars and
> constants (it's a big jextract command)
>
> So in the need of new functions from C to java, some might need to
> re-generate the bindings and it
> would be useful to have a gradle task for that, or any other way of
> re-generating it.
>
> Less important, but I need clearance to push it to javafx sandbox if I
> touch any new API, but I think (but not sure) it would be easier (to get
> clearance) if
> I don't include the actual binding to the API, but the binding generation
> (so the user of the branch generates it on his own machine).
>
>
>
> Em dom., 17 de nov. de 2024 ?s 19:23, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> The question is: what are you binding to? If it's a library on the OS
>> that gets updated from time to time and JavaFX relies on it being there
>> (not bundled), then the generated bindings in a task could change and break
>> compilation if the Java code wasn't changed. If it's a library created by
>> JavaFX, like the bindings to graphic pipelines, then you won't want to
>> re-run the task until you actually change the native side yourself.
>>
>> On Sun, Nov 17, 2024 at 6:44?PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>> I was thinking about including a generation task as part of the build.
>>> But you're right, I can make a simpler task that generates it by running
>>> jextract only on demand rather than being part of the build.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Em dom., 17 de nov. de 2024 ?s 13:18, Nir Lisker <nlisker at gmail.com>
>>> escreveu:
>>>
>>>> jextract is something you run once to produce the FFM bindings that you
>>>> then add to your code base, there's no need to make it part of the build
>>>> (although I guess you can). I would think that If you're creating a PR that
>>>> needs FFM, use jextract to produce the java files and submit them as part
>>>> of the PR. Not sure what package arrangement is suitable.
>>>>
>>>> On Sun, Nov 17, 2024 at 4:29?PM Thiago Milczarek Say?o <
>>>> thiago.sayao at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Are there any plans to make a default way to use jextract (or any
>>>>> other way to use ffm) on the gradle build system?
>>>>>
>>>>> -- Thiago
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241118/4e9b08dc/attachment.htm>

From arapte at openjdk.org  Mon Nov 18 11:52:12 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 11:52:12 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v3]
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1637/files
  - new: https://git.openjdk.org/jfx/pull/1637/files/c3395cce..e275089e

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

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

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

From arapte at openjdk.org  Mon Nov 18 11:52:12 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 11:52:12 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <Yb6u3Nc8yxPrIm0QPjAF3eCmYzjn2x43dgz93px2Awo=.128a94a9-16dc-4fe4-b1ab-524cd3b820c0@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
 <8khEJKFeeEi28yd6AUT1FxOpF_gRpn28s5Vxo_c7ddk=.10af52f5-d4fd-41d8-8b5c-a1c02c0d1210@github.com>
 <pLPXk2q6NFd17ER0v79cZNBcRcv8xKPhjaGmExTdgYs=.9e5a3b63-a4e3-4453-97e1-1e6ba0f74499@github.com>
 <Yb6u3Nc8yxPrIm0QPjAF3eCmYzjn2x43dgz93px2Awo=.128a94a9-16dc-4fe4-b1ab-524cd3b820c0@github.com>
Message-ID: <vnj1jP3PCxAU0EAcWK6l0twXKdqCmS3jOfzftcXFIWU=.af51ffdd-c2fb-4607-9b6d-6e369c426047@github.com>

On Sun, 17 Nov 2024 09:06:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

>>> I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable.
>> 
>> Also at the risk of sounding like a broken record, https://github.com/openjdk/jfx/pull/1232 has been waiting to start this process for a while now and it's stuck waiting for explanations on how publishing works, something only Oracle and Gluon do. If someone can help Jendrik Johannes there then the ball will get rolling. I tried to split the big build file into separate files for each module, but it's entangled with the code in that PR. Completing that PR might also remove the need for the JavaFX plugin.
>
>> > I know I'm a broken record on this topic, but if possible, it would be great if (parts of) this logic can be moved into a separate file in order to make the build.gradle smaller and more readable.
>> 
>> Also at the risk of sounding like a broken record, #1232 has been waiting to start this process for a while now and it's stuck waiting for explanations on how publishing works, something only Oracle and Gluon do. If someone can help Jendrik Johannes there then the ball will get rolling. I tried to split the big build file into separate files for each module, but it's entangled with the code in that PR. Completing that PR might also remove the need for the JavaFX plugin.
> 
> Fair remark. I just commented on the PR.

Added `relOpt = "-${buildTimestamp}" `

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1846451604

From arapte at openjdk.org  Mon Nov 18 11:52:13 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 11:52:13 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <EqzqSeRyXZd1zNgD5xus8apBQcibCWJr0GAyY9EmgWo=.5e18e02c-a2e0-41f3-bede-389baf781067@github.com>
Message-ID: <nCNNMUa36H_86nhsyIF0FH1KMFT2BD0I2V0vmUTbg3g=.bb6559a2-f99b-487e-980e-6d38fd023412@github.com>

On Sat, 16 Nov 2024 15:12:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte 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 'master' into exp-suffix
>>  - 8343196: Add build property to identify experimental builds of JavaFX
>
> build.properties line 42:
> 
>> 40: 
>> 41: # The experimental release suffix is set only in jfx-sandbox repository
>> 42: # for a speficic branch. When this property is set it overrides
> 
> Do you want to say something about it needing to start with a `-`? Or do you think the example of `-ea` above will be clear enough?

Added a comment to describe the use of `-`, with example of `-metal` and -`d3d12`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1846451799

From arapte at openjdk.org  Mon Nov 18 12:11:17 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 12:11:17 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v3]
In-Reply-To: <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>
Message-ID: <sTjEDpCjlVL4o2vB2STX0wM36NRNKnspIfrf82sYm8c=.e8f7e792-73c3-4358-83cd-bb4e73efb6b0@github.com>

On Mon, 18 Nov 2024 11:52:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Why we chose the name `jfx.experimental.release.suffix`.
The JavaFX version string contains the value of `jfx.release.suffix` i.e  `-ea` as a suffix. The new variable would be doing same, so it is also a suffix.
`24-ea` would be now `24-metal`

and use of `experimental` is justified by @nlisker as:
> I would have went with jfx.experimental.name :) because the sandbox has experimental features, as opposed to other features that are directly integrated into the main stream.

`jfx.release.suffix` **:** JavaFX relase version suffix for early access releases i.e `-ea`
`jfx.experimental.release.suffix` **:** JavaFX relase version suffix for experimental releases.

With this understanding, I am happy with the current name :) but shall update the PR we finalize any other name.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2482858940

From kcr at openjdk.org  Mon Nov 18 14:49:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 14:49:54 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v3]
In-Reply-To: <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>
Message-ID: <9TtDprfCu-gC1A5K1DUeqcNjsUqt31mQgGdQH8zcTPg=.77f1036e-972f-4d6b-a1b2-0b75665c9e7c@github.com>

On Mon, 18 Nov 2024 11:52:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

I'd rather have the property be something without `suffix` for the reasons Johan and I mentioned.

Even though it's a little longer, I like a combination of what Johan and Nir suggested:

`jfx.experimental.feature.name` -- The name of the experimental feature

No one will ever specify this on the command line or have to type it, so having it be more explicit is good, even though the name is a little long.

You can say something like:

Set this property to the name of the experimental feature for your branch. Do not include a dash in the name. For example, if you have a sandbox branch named `myfeature` you might set `jfx.experimental.feature.name=myfeature`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2483263319

From angorya at openjdk.org  Mon Nov 18 15:47:15 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 15:47:15 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v3]
In-Reply-To: <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>
Message-ID: <5brfyEB9W77wawZ3pMZYz_h_4gZ8Vu_8CDDx_MTjbIg=.914b4c20-d055-4e8b-9dac-2843dc657c54@github.com>

On Sat, 16 Nov 2024 14:29:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
>> 
>> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
>> 
>> ### Notes to reviewers
>> 
>> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
>> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

lgtm

The remaining AC/ACC in ios and android directories:


ExportedJavaObject.java - jfx/modules/javafx.web/src/ios/java/javafx/scene/web (2 matches)
HTMLEditorSkin.java - jfx/modules/javafx.web/src/ios/java/javafx/scene/web (6 matches)
Timer.java - jfx/modules/javafx.web/src/android/java/com/sun/webkit (2 matches)
WebEngine.java - jfx/modules/javafx.web/src/android/java/javafx/scene/web (2 matches)
WebEngine.java - web/src/android/java/javafx/scene/web (2 matches)
WebPage.java - jfx/modules/javafx.web/src/android/java/com/sun/webkit (2 matches)

ExportedJavaObject.java - jfx/modules/javafx.web/src/ios/java/javafx/scene/web
JS2JavaBridge.java - jfx/modules/javafx.web/src/ios/java/javafx/scene/web (4 matches)
WebEngine.java - jfx/modules/javafx.web/src/android/java/javafx/scene/web
WebEngine.java - web/src/android/java/javafx/scene/web
WebPage.java - jfx/modules/javafx.web/src/android/java/com/sun/webkit (3 matches)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1638#pullrequestreview-2443022530
PR Comment: https://git.openjdk.org/jfx/pull/1638#issuecomment-2483421527

From angorya at openjdk.org  Mon Nov 18 15:55:48 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 15:55:48 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
In-Reply-To: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
References: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
Message-ID: <g6eQDOFy9dMasPLOgMVsNMMqUDMnBKV5d4OwsNqzvO8=.d3c83f6e-018d-49b9-a7c3-105ad3cd6070@github.com>

On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A batch of typo and grammar fixes that were found by the spellchecker.
> 
> Integration can wait until RDP 1/2.

thank you for fixing these errors (from a guy who contributed at least one)!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1642#pullrequestreview-2443041867

From angorya at openjdk.org  Mon Nov 18 16:23:49 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 16:23:49 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton
In-Reply-To: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
Message-ID: <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>

On Sat, 16 Nov 2024 00:58:47 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> There are multiple issues in the `TableMenu` logic that result in a memory leak.
> 
> The following problems are now fixed with this PR:
> - The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
>    - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
> - The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
>   - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 641:

> 639: 
> 640:             final CheckMenuItem _item = item;
> 641:             // fake bidrectional binding (a real one was used here but resulted in JBS-8136468)

that's JDK-8136468

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewTableHeaderRowTest.java line 233:

> 231:     /**
> 232:      * Tests that re-setting the same columns does not cause memory leaks.
> 233:      * See also: <a href="https://bugs.openjdk.org/browse/JDK-8341687">JDK-8341687</a>.

technically, this test does not test for memory leak - it seems to test the fact that the listener gets disconnected.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewTableHeaderRowTest.java line 261:

> 259:     /**
> 260:      * Tests that toggling the column visibility does not cause memory leaks.
> 261:      * See also: <a href="https://bugs.openjdk.org/browse/JDK-8341687">JDK-8341687</a>.

same comment - does not test for memory leak.  the memory leak test might involve `JMemoryBuddy` - see for example `SystemMenuBarTest`.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableViewTableHeaderRowTest.java line 234:

> 232:     /**
> 233:      * Tests that re-setting the same columns does not cause memory leaks.
> 234:      * See also: <a href="https://bugs.openjdk.org/browse/JDK-8341687">JDK-8341687</a>.

same, does not test for leaks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1846878710
PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1846882432
PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1846887787
PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1846889065

From nlisker at openjdk.org  Mon Nov 18 16:30:23 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Nov 2024 16:30:23 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
In-Reply-To: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
References: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
Message-ID: <au19PJklunDa8xFFn9VppAuVc6AvgPmOil_VYlLFExo=.4316bbf9-7f8f-4170-bbf8-2bf8c3a7850b@github.com>

On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A batch of typo and grammar fixes that were found by the spellchecker.
> 
> Integration can wait until RDP 1/2.

I will wait with integration to see what else can be accumulated until the RDPs.

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

PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2483527731

From angorya at openjdk.org  Mon Nov 18 16:36:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 16:36:11 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
In-Reply-To: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
References: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
Message-ID: <h-vSBVYL8CK62v1847_8OPtaLZycJmjwm5ePmE0fCfY=.4abf84eb-b1c7-4733-9fa4-7c1f04ad2cba@github.com>

On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A batch of typo and grammar fixes that were found by the spellchecker.
> 
> Integration can wait until RDP 1/2.

BTW, did you use IDE for this (and which one)?

Eclipse does highlight spelling errors inline when enabled, but I could not find a way to list all of them in the Problems view.

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

PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2483543773

From kcr at openjdk.org  Mon Nov 18 17:45:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 17:45:52 GMT
Subject: RFR: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX [v3]
In-Reply-To: <5brfyEB9W77wawZ3pMZYz_h_4gZ8Vu_8CDDx_MTjbIg=.914b4c20-d055-4e8b-9dac-2843dc657c54@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
 <7tk-NsEkpL-4ZbhhnGkZuFO3_2j47d7Zxo8Y_J7Casw=.b895df16-f109-4e8c-b04e-41f86d4befa2@github.com>
 <5brfyEB9W77wawZ3pMZYz_h_4gZ8Vu_8CDDx_MTjbIg=.914b4c20-d055-4e8b-9dac-2843dc657c54@github.com>
Message-ID: <FAz21aMU4DIubpSVnDzGjNmilJDzRrsEp0H1CgYqBWc=.a43b4b07-c1c2-4e88-add1-05588570fdcb@github.com>

On Mon, 18 Nov 2024 15:44:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The remaining AC/ACC in ios and android directories:

Thanks. I filed [JDK-8344431](https://bugs.openjdk.org/browse/JDK-8344431) to track this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1638#issuecomment-2483710461

From kcr at openjdk.org  Mon Nov 18 17:45:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 17:45:53 GMT
Subject: Integrated: 8342993: Remove uses of AccessController and
 AccessControlContext from JavaFX
In-Reply-To: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
References: <k-JJwvtU0ps_eyo_hyDpHXd5GGf246NjbtU_yYK_7mQ=.4e0941fe-82b7-413e-9819-b9a611268c7b@github.com>
Message-ID: <9XOKq2LBA6cprkxK_OX8s8eMPBWa5S5XS4nQIJ6tlXc=.cab497da-18f7-464d-9ed3-914e27e91a7b@github.com>

On Thu, 14 Nov 2024 20:59:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes all remaining uses of `AccessController` and `AccessControlContext`, which represent the last remaining uses of the terminally deprecated security APIs except for those in the `/ios/` or `/android/` directories.
> 
> With the removal of doPrivileged and the `if (System.getSecurityManager() != null)` code paths, the ACC is no longer used, so can be completely eliminated. Along with this, I removed all unused imports of security-related APIs and all related `@SuppressWarnings("removal") annotations.
> 
> ### Notes to reviewers
> 
> * Most of the changes were straight-forward removals of methods and fields to save, retrieve and pass around the `AccessControlContext`.
> * The Toolkit class stores a collection of listeners in a `WeakHashMap` with the listener as the key (thus weakly held) and the ACC as the value. We no longer need or want the ACC, but I kept the use of `WeakHashMap` and changed the value type to `Object`, storing a singleton dummy object as the value for each entry. This minimizes the changes, while preserving the behavior of reclaiming the entries when they are garbage collected.

This pull request has now been integrated.

Changeset: 7d1b2c3e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7d1b2c3e6914ad60ccfc60d9d17dc6dcb7780ae3
Stats:     327 lines in 30 files changed: 8 ins; 261 del; 58 mod

8342993: Remove uses of AccessController and AccessControlContext from JavaFX

Reviewed-by: angorya, mstrauss

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

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

From arapte at openjdk.org  Mon Nov 18 18:12:35 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 18:12:35 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v4]
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <2CfwLxjQOX7SdNlkxNsWp5jvPYFqjseNlLZruIGc7l4=.c122cd35-03b4-44a4-b484-8c80a4db4fba@github.com>

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

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

  change property name to jfx.experimental.feature.name

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1637/files
  - new: https://git.openjdk.org/jfx/pull/1637/files/e275089e..ee7b69bd

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

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

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

From arapte at openjdk.org  Mon Nov 18 18:12:36 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 18:12:36 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v3]
In-Reply-To: <9TtDprfCu-gC1A5K1DUeqcNjsUqt31mQgGdQH8zcTPg=.77f1036e-972f-4d6b-a1b2-0b75665c9e7c@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <QViUStSrs5DoWs2QdA1Oea1hqlHZIrvlGUKbkLOviu8=.1ae38ccc-b205-4c41-adc0-78f15747ddc6@github.com>
 <9TtDprfCu-gC1A5K1DUeqcNjsUqt31mQgGdQH8zcTPg=.77f1036e-972f-4d6b-a1b2-0b75665c9e7c@github.com>
Message-ID: <FUTWCpIPEOnX7c0-7ClCV9I1N7J3zQuTkEK_YN9j3os=.798fe016-280d-4003-ad17-19f0bd449287@github.com>

On Mon, 18 Nov 2024 14:46:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> `jfx.experimental.feature.name` -- The name of the experimental feature

Thanks @kevinrushforth , Updated the property name as suggested.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2483775795

From kcr at openjdk.org  Mon Nov 18 19:04:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 19:04:41 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
Message-ID: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>

This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.

This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

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

Commit messages:
 - 8344443: Deprecate FXPermission for removal

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

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

From angorya at openjdk.org  Mon Nov 18 19:16:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 19:16:11 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <Lxxhd3nLrd9vq49PZSAltOtEarkvja88prtanb_mSQA=.eba1d588-518e-4ef4-937c-5cf26f96926c@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

modules/javafx.base/src/main/java/javafx/util/FXPermission.java line 48:

> 46:  *
> 47:  * @deprecated This class was only useful in connection with the
> 48:  *       Security Manager, which is no longer supported.

should it be SecurityManager (as in class name)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1643#discussion_r1847119466

From kcr at openjdk.org  Mon Nov 18 19:51:43 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 19:51:43 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v3]
In-Reply-To: <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
Message-ID: <sK7FDF_CKMDdGCl_apwytd28Gy1fO11tVB1BE7c_e08=.ce49d176-abe2-462a-818e-937eff31ed9b@github.com>

On Sat, 16 Nov 2024 20:19:06 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - formatting
>  - ParameterizedTest

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1639#pullrequestreview-2443553301

From kcr at openjdk.org  Mon Nov 18 19:51:44 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 19:51:44 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v2]
In-Reply-To: <aKi8rsplsjvZDNzDbaNWOA9DwwibfnPhSvGziLMZGAg=.ae686ec2-0a01-4168-b20a-e17d76ef4856@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <NAP6QXo4h6yk-PYutHx9sd11wSYKdD29a9HmnAWRBVE=.307e81cd-1114-460e-a257-0e08d6408a4f@github.com>
 <O9XAKaVBf8MLkSgzEZxjQSxpMz67S2cfIDwgKD6lgxw=.d39de4e2-713e-487c-beee-09734940a61d@github.com>
 <aKi8rsplsjvZDNzDbaNWOA9DwwibfnPhSvGziLMZGAg=.ae686ec2-0a01-4168-b20a-e17d76ef4856@github.com>
Message-ID: <7T4iUVfsWJKAEo6U8ZVHs5eglnUAQMSxPJL1ehYA1KY=.f0d61310-eda3-494a-8de4-2ae2e80abc86@github.com>

On Sat, 16 Nov 2024 20:37:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> > I can't reproduce the crash without this fix on my system, but since it does happen on some systems, it does need to be fixed.
> 
> Just to be on the same page, it still crashes for me (at least on Ubuntu 22.04) as expected for the following scenarios:
> 
> 1. Do one of the following
>    
>    1. Build the JDK's [/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) full changeset + take some JFX build without this PR(aka any random JFX build).

Yes, this is what I was running: a locally-built JDK with the complete patch from JDK PR 22131 + FX 24-ea without your FX fix from this PR.

On Ubuntu 24.04 the test hung, but did not crash. Today, when I ran it on an Ubuntu 22.04 VM I was able to reproduce the crash one time (and it hung two other times, so it appears that whether or not it will crash is intermittent).

>    2. Build the JDK with only an [a. part](https://github.com/openjdk/jdk/pull/22131#a-part) + JFX build with this PR

I did not try this. What I did try is a JDK 23 without any part of your JDK fix + FX with the patch from this PR. That hangs, but does not crash.

Anyway, all looks good to me.

>> tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 72:
>> 
>>> 70:     private static void awtPixelOnFxThread() throws InterruptedException {
>>> 71:         System.out.println("awtPixelOnFxThread");
>>> 72:         initFX();
>> 
>> Have you considered moving the `initFX()` call to the `init` method (after the call to AWT robot) so you only need it in one place?
>
> It is intentionally kept out of the `init()` method to be able to test the
> 
>> 1. If there is no GTK main loop running
> Example: just a JDK only application.
> In this case we call g_main_context_iteration(NULL, TRUE) as before (when [gtk_main_level() == 0](https://docs.gtk.org/gtk3/func.main_level.html)).
> 
> like
> 
> 
> awtPixel();
> robot.delay(DELAY_WAIT_FOR_SESSION_TO_CLOSE);
> 
> initFX();
> robot.delay(500);
> awtPixel();

OK

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2483955713
PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1847158672

From kcr at openjdk.org  Mon Nov 18 19:56:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 19:56:12 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <Lxxhd3nLrd9vq49PZSAltOtEarkvja88prtanb_mSQA=.eba1d588-518e-4ef4-937c-5cf26f96926c@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
 <Lxxhd3nLrd9vq49PZSAltOtEarkvja88prtanb_mSQA=.eba1d588-518e-4ef4-937c-5cf26f96926c@github.com>
Message-ID: <3K9W3Gpctb3uKevCXn5G7CANqx5hTDRgQH9EmCPy1N4=.5331fa99-af2d-4034-baf5-13831d2aa71a@github.com>

On Mon, 18 Nov 2024 19:13:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
>> 
>> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.
>
> modules/javafx.base/src/main/java/javafx/util/FXPermission.java line 48:
> 
>> 46:  *
>> 47:  * @deprecated This class was only useful in connection with the
>> 48:  *       Security Manager, which is no longer supported.
> 
> should it be SecurityManager (as in class name)?

No, this refers to "the Security Manager" as a feature, which is more than the `SecurityManager` class. See https://openjdk.org/jeps/486.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1643#discussion_r1847166090

From angorya at openjdk.org  Mon Nov 18 20:00:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 20:00:12 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <B8Hbn8-XGbZpGsHSCv9YsPjBYM7Bavt41uSeRW3UEyQ=.654cca6c-497e-4b12-b700-a28e3024ab9d@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1643#pullrequestreview-2443576546

From mhanl at openjdk.org  Mon Nov 18 20:17:55 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 18 Nov 2024 20:17:55 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton
In-Reply-To: <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
Message-ID: <xXea14Urok1S95wQroZ4yM5Is0BO_gCBooJTX_9u3o0=.338baff8-431a-4c6d-8290-1fc998e21185@github.com>

On Mon, 18 Nov 2024 16:19:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There are multiple issues in the `TableMenu` logic that result in a memory leak.
>> 
>> The following problems are now fixed with this PR:
>> - The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
>>    - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
>> - The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
>>   - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewTableHeaderRowTest.java line 261:
> 
>> 259:     /**
>> 260:      * Tests that toggling the column visibility does not cause memory leaks.
>> 261:      * See also: <a href="https://bugs.openjdk.org/browse/JDK-8341687">JDK-8341687</a>.
> 
> same comment - does not test for memory leak.  the memory leak test might involve `JMemoryBuddy` - see for example `SystemMenuBarTest`.

I tried, but it isn't that easy - since the memory is not leaked because we keep some references we should not keep - rather we are adding listener again and again and again. So we can not assert things to be collectable, as they should not be, still they increase the memory footprint instead.

So I did not manage to make a test with `JMemoryBuddy`, but can prove the point with the amount of listener instead.

I wrote a test that checked, that the memory is similar high as before, that worked as well but I was afraid that is might be flaky, which I want to avoid.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1847209388

From angorya at openjdk.org  Mon Nov 18 20:24:13 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Nov 2024 20:24:13 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton
In-Reply-To: <xXea14Urok1S95wQroZ4yM5Is0BO_gCBooJTX_9u3o0=.338baff8-431a-4c6d-8290-1fc998e21185@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <xXea14Urok1S95wQroZ4yM5Is0BO_gCBooJTX_9u3o0=.338baff8-431a-4c6d-8290-1fc998e21185@github.com>
Message-ID: <wiBVo0ULCGioa2SLzX0Alg2VnDcaHXkWFJBNfdO0pOY=.7e7144fa-29ce-4e06-8b3c-2880df4c2a9e@github.com>

On Mon, 18 Nov 2024 20:11:50 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewTableHeaderRowTest.java line 261:
>> 
>>> 259:     /**
>>> 260:      * Tests that toggling the column visibility does not cause memory leaks.
>>> 261:      * See also: <a href="https://bugs.openjdk.org/browse/JDK-8341687">JDK-8341687</a>.
>> 
>> same comment - does not test for memory leak.  the memory leak test might involve `JMemoryBuddy` - see for example `SystemMenuBarTest`.
>
> I tried, but it isn't that easy - since the memory is not leaked because we keep some references we should not keep - rather we are adding listener again and again and again. So we can not assert things to be collectable, as they should not be, still they increase the memory footprint instead.
> 
> So I did not manage to make a test with `JMemoryBuddy`, but can prove the point with the amount of listener instead.
> 
> I wrote a test that checked, that the memory is similar high as before, that worked as well but I was afraid that is might be flaky, which I want to avoid.

I think this is an acceptable explanation as it tests the root cause of the leak.

Do you think changing the skin would allow us to create a test for the memory leak specifically.  Maybe some variation of `SkinMemoryLeakTest` ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1847219724

From kcr at openjdk.org  Mon Nov 18 20:52:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 20:52:11 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <SaOby5eiIUocuHRg-Otr4GaeM2ZqnkaBMrp0hEbeLVA=.44089b74-5bbc-4ede-8501-4d20b6d1d1ee@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

@arapte Can you be the second reviewer?

@prrace You might want to take a look as well, since you are planning to do the same thing for `AWTPermission` at some point.

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

PR Comment: https://git.openjdk.org/jfx/pull/1643#issuecomment-2484101576

From arapte at openjdk.org  Mon Nov 18 20:56:44 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 20:56:44 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v5]
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <TqD-MqHTa7w63SgstPW3-pe6rkx6zyBQaAG4k4r2YOY=.c52c8ba8-5825-4081-b757-6096113eca77@github.com>

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

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

  correcttion

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1637/files
  - new: https://git.openjdk.org/jfx/pull/1637/files/ee7b69bd..bbe492aa

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

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

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

From arapte at openjdk.org  Mon Nov 18 21:13:54 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Nov 2024 21:13:54 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <AxpdyzQyb50sfp53qv4FublF-jgC7lw8a3Axj1Agtyo=.9e3a6c31-1759-428b-b49e-795694f9d80e@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

LGTM, FXPermission is not used anywhere.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1643#pullrequestreview-2443741183

From kcr at openjdk.org  Mon Nov 18 21:24:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 21:24:52 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v5]
In-Reply-To: <TqD-MqHTa7w63SgstPW3-pe6rkx6zyBQaAG4k4r2YOY=.c52c8ba8-5825-4081-b757-6096113eca77@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <TqD-MqHTa7w63SgstPW3-pe6rkx6zyBQaAG4k4r2YOY=.c52c8ba8-5825-4081-b757-6096113eca77@github.com>
Message-ID: <56qXqXpTvBkb4x45NjOxDFxRC60o2866nIssGqLqlck=.0a9a958e-5afb-4399-9364-d398cd8bc717@github.com>

On Mon, 18 Nov 2024 20:56:44 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcttion

Looks good with one suggested change.

build.gradle line 706:

> 704:         relSuffix = jfxExperimentalFeatureName != "" ?
> 705:                         "-${jfxExperimentalFeatureName}" : jfxReleaseSuffix;
> 706:         relOpt = "-${buildTimestamp}"

This will unconditionally add a timestamp to _all_ EA builds of JavaFX, not just experimental builds. Changing the version string for EA builds seems out of scope for this PR.

Suggestion:

        if (jfxExperimentalFeatureName != "") {
            relSuffix = "-${jfxExperimentalFeatureName}"
            relOpt = "-${buildTimestamp}"
        } else {
            relSuffix = jfxReleaseSuffix
        }

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

PR Review: https://git.openjdk.org/jfx/pull/1637#pullrequestreview-2443738897
PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1847283536

From ambarish.rapte at oracle.com  Mon Nov 18 21:44:17 2024
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 18 Nov 2024 21:44:17 +0000
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
In-Reply-To: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com>
Message-ID: <PH7PR10MB7850F5550974EA90D6320B4EF0272@PH7PR10MB7850.namprd10.prod.outlook.com>

Vote: YES

--Ambarish
From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, 12 November 2024 at 21:53
To: openjfx-dev <openjfx-dev at openjdk.org>, Lukasz Kostyra <lukasz.kostyra at oracle.com>
Subject: CFV: New OpenJFX Reviewer: Lukasz Kostyra
I hereby nominate Lukasz Kostyra [1] to OpenJFX Reviewer.

Lukasz is a member of JavaFX team at Oracle, who has contributed 35
commits [2] to OpenJFX. Lukasz consistently participates in code reviews
of various pull requests, especially in the graphics area.

Votes are due by Nov 26, 2024 at 17:00 UTC.

Only current OpenJFX Reviewers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4]. Nomination to a
project Reviewer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#lkostyra

[2]
https://github.com/openjdk/jfx/search?q=author-name%3A%22Lukasz+Kostyra%22&s=author-date&type=commits

[3] https://openjdk.java.net/census#openjfx

[4] https://openjdk.java.net/bylaws#three-vote-consensus

[5] https://openjdk.java.net/projects#project-reviewer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241118/849d6aaf/attachment.htm>

From kcr at openjdk.org  Mon Nov 18 22:25:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Nov 2024 22:25:54 GMT
Subject: RFR: 8338000: Remove GlassFullscreenWindow
In-Reply-To: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
References: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
Message-ID: <eC38N_6AHJ6t-57bkPhLzKtn2YwaR8HRks_ipPSlnWY=.f90ded49-29e2-4c21-9c23-567a1c62dce8@github.com>

On Sun, 17 Nov 2024 20:18:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

Nice cleanup.

I reviewed all of the code changes, and this all looks good. In addition to reviewing it, I instrumented the code to verify that `fullScreenWindow` is always null (it is). After applying your patch, I see no more references to the dead classes and the unused (always null) `fullScreenWindow` and `fsWindow` fields.

I fired off a headful test build on our macOS platforms and will approve it once it passes.

@beldenfox You will need to change the title of this PR to match the JBS title (I modified it slightly for consistency, but the mismatch was there before I did that).

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

PR Comment: https://git.openjdk.org/jfx/pull/1641#issuecomment-2484259291

From arapte at openjdk.org  Tue Nov 19 04:34:05 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Nov 2024 04:34:05 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v6]
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <suc8MsKSbq098YFqZwdg7KknioN2TXP-kuas7-2dh5k=.dafae5d5-287f-42d1-8785-9143392fe0b7@github.com>

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

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

  Update build.gradle
  
  Review correction
  
  Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1637/files
  - new: https://git.openjdk.org/jfx/pull/1637/files/bbe492aa..26e7790b

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

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

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

From arapte at openjdk.org  Tue Nov 19 04:36:48 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Nov 2024 04:36:48 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v5]
In-Reply-To: <56qXqXpTvBkb4x45NjOxDFxRC60o2866nIssGqLqlck=.0a9a958e-5afb-4399-9364-d398cd8bc717@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <TqD-MqHTa7w63SgstPW3-pe6rkx6zyBQaAG4k4r2YOY=.c52c8ba8-5825-4081-b757-6096113eca77@github.com>
 <56qXqXpTvBkb4x45NjOxDFxRC60o2866nIssGqLqlck=.0a9a958e-5afb-4399-9364-d398cd8bc717@github.com>
Message-ID: <2_RsXPQvD3tbKjsn7tyGghhr7H8QyzV4BG6EQkk1dUA=.28c63bf6-14ff-4d15-9bf9-e09e2d0429c6@github.com>

On Mon, 18 Nov 2024 21:13:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correcttion
>
> build.gradle line 706:
> 
>> 704:         relSuffix = jfxExperimentalFeatureName != "" ?
>> 705:                         "-${jfxExperimentalFeatureName}" : jfxReleaseSuffix;
>> 706:         relOpt = "-${buildTimestamp}"
> 
> This will unconditionally add a timestamp to _all_ EA builds of JavaFX, not just experimental builds. Changing the version string for EA builds seems out of scope for this PR.
> 
> Suggestion:
> 
>         if (jfxExperimentalFeatureName != "") {
>             relSuffix = "-${jfxExperimentalFeatureName}"
>             relOpt = "-${buildTimestamp}"
>         } else {
>             relSuffix = jfxReleaseSuffix
>         }

Thanks @kevinrushforth , Included the change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1637#discussion_r1847626483

From lkostyra at openjdk.org  Tue Nov 19 11:48:49 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 19 Nov 2024 11:48:49 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v3]
In-Reply-To: <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
Message-ID: <Pvqec35vK7wwT-HLIZo58y8MoT6LJY5659Zlsi_ibYQ=.2180bbcf-5203-4568-9dde-7f3a718b3c92@github.com>

On Sat, 16 Nov 2024 20:19:06 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - formatting
>  - ParameterizedTest

Code-wise looks good. I wanted to verify the patch on my end, but I need to get up to speed with JDK repos to build it with your other change. I'll try to get it approved tomorrow, assuming it all works well.

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

PR Review: https://git.openjdk.org/jfx/pull/1639#pullrequestreview-2445203060

From kcr at openjdk.org  Tue Nov 19 13:18:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Nov 2024 13:18:12 GMT
Subject: RFR: 8338000: Remove GlassFullscreenWindow
In-Reply-To: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
References: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
Message-ID: <hvb1_nfI8E1tWOivEfmRPKdmk5bcHEjQnK1dXbfrrpQ=.62696381-00f5-47a4-991d-64f6c5ab7ae7@github.com>

On Sun, 17 Nov 2024 20:18:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1641#pullrequestreview-2445440719

From kcr at openjdk.org  Tue Nov 19 16:40:57 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Nov 2024 16:40:57 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v6]
In-Reply-To: <suc8MsKSbq098YFqZwdg7KknioN2TXP-kuas7-2dh5k=.dafae5d5-287f-42d1-8785-9143392fe0b7@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <suc8MsKSbq098YFqZwdg7KknioN2TXP-kuas7-2dh5k=.dafae5d5-287f-42d1-8785-9143392fe0b7@github.com>
Message-ID: <MaPjYOtwjOa18yzHIKpoEhBIWDH1wFrVdr7zENraTHg=.110b93a6-b196-4776-b4d9-1f839b90d291@github.com>

On Tue, 19 Nov 2024 04:34:05 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update build.gradle
>   
>   Review correction
>   
>   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1637#pullrequestreview-2446020423

From kcr at openjdk.org  Tue Nov 19 16:44:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Nov 2024 16:44:54 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v2]
In-Reply-To: <YVGz5AIXqmDZjjBBstSjoMYGAWijHbRA2QE2vSUuIAM=.1baad08b-2e46-4420-a9ff-405228d5c83e@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <bLmbrsyWP9_WpDHOBJT6ugIOYcZ1iIYEH0nRpX2Yh0M=.84ddedd1-9244-46d3-af23-d4b5e2aabdb1@github.com>
 <CTGRKKa4sGrJ5RBeFk78Rytb5qjar5GVvsDlNk09Tq0=.82cb6d2b-18ab-4d5a-8e02-ed13b29fefbe@github.com>
 <YVGz5AIXqmDZjjBBstSjoMYGAWijHbRA2QE2vSUuIAM=.1baad08b-2e46-4420-a9ff-405228d5c83e@github.com>
Message-ID: <VNi6lrbnuKylxvw8PTguZmJii3bn6fFkiWz9-z-ZhNQ=.95940de4-cfbf-4578-b945-0f5256838f65@github.com>

On Sun, 17 Nov 2024 09:02:56 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> If we do this, then here are some possible names:
>> 
>> * jfx.experimental.release
>> * jfx.experimental.release.name
>> * jfx.variant.release
>> * jfx.variant.release.name
>> * jfx.variant
>> * jfx.feature.variant
>> 
>> Thoughts?
>
>> If we do this, then here are some possible names:
>> 
>> * jfx.experimental.release
>> * jfx.experimental.release.name
>> * jfx.variant.release
>> * jfx.variant.release.name
>> * jfx.variant
>> * jfx.feature.variant
>> 
>> Thoughts?
> 
> I don't have objections against any of those.
> If I have to vote, my vote would go to "jfx.feature.name" (which is not in the list ;) ) because I associate variant rather with a single option from a wider set (e.g. prism variants are sw, es2,,...)
> But I am more than happy with any name on this list.

Looks good now. @johanvos this should be ready for your review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2486219699

From kevin.rushforth at oracle.com  Tue Nov 19 17:16:56 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 19 Nov 2024 09:16:56 -0800
Subject: =?UTF-8?Q?Result=3A_New_OpenJFX_Reviewer=3A_Michael_Strau=C3=9F?=
Message-ID: <2a0f7e0d-4e92-4d3a-abfb-704981bf4c43@oracle.com>

Voting for Michael Strau? [1] to OpenJFX Reviewer [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is 
sufficient to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#mstrauss
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050551.html


From andy.goryachev at oracle.com  Tue Nov 19 17:50:25 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 19 Nov 2024 17:50:25 +0000
Subject: =?iso-8859-1?Q?Re:_Result:_New_OpenJFX_Reviewer:_Michael_Strau=DF?=
In-Reply-To: <2a0f7e0d-4e92-4d3a-abfb-704981bf4c43@oracle.com>
References: <2a0f7e0d-4e92-4d3a-abfb-704981bf4c43@oracle.com>
Message-ID: <BYAPR10MB3013AF52CF8BD775952CD335E5202@BYAPR10MB3013.namprd10.prod.outlook.com>

Congratulations, Michael!

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Tuesday, November 19, 2024 at 09:17
To: registrar <registrar at openjdk.org>, Michael Strau? <michaelstrau2 at gmail.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Result: New OpenJFX Reviewer: Michael Strau?
Voting for Michael Strau? [1] to OpenJFX Reviewer [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#mstrauss
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050551.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241119/3ecd3882/attachment-0001.htm>

From angorya at openjdk.org  Tue Nov 19 19:43:58 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 19 Nov 2024 19:43:58 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v5]
In-Reply-To: <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com>
Message-ID: <DV6KBVtNyLAnpNg41XBWF1J4w8YKJr-tyfcY4GV_CQo=.391db04d-f498-4c84-9612-832c8d9f1c12@github.com>

On Mon, 4 Nov 2024 17:21:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
>> 
>> Removed earlier manual tester in favor of the monkey tester.
>> 
>> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - in case of hitting min max
>  - Merge branch 'master' into 8299753.resize
>  - Merge branch 'master' into 8299753.resize
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - Merge branch 'master' into 8299753.resize
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - Merge remote-tracking branch 'origin/master' into 8299753.resize
>  - ... and 28 more: https://git.openjdk.org/jfx/compare/5bf02be0...7c947083

please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2486595422

From jvos at openjdk.org  Tue Nov 19 20:16:51 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 19 Nov 2024 20:16:51 GMT
Subject: RFR: 8343196: Add build property to identify experimental builds
 of JavaFX [v6]
In-Reply-To: <suc8MsKSbq098YFqZwdg7KknioN2TXP-kuas7-2dh5k=.dafae5d5-287f-42d1-8785-9143392fe0b7@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
 <suc8MsKSbq098YFqZwdg7KknioN2TXP-kuas7-2dh5k=.dafae5d5-287f-42d1-8785-9143392fe0b7@github.com>
Message-ID: <QB9zqwa24ErMUzMX3JlRMo7t8k-EDUJKR1pHf4s0DP8=.4e423c80-8c75-46c8-bda4-0a291ab6d622@github.com>

On Tue, 19 Nov 2024 04:34:05 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update build.gradle
>   
>   Review correction
>   
>   Co-authored-by: Kevin Rushforth <kevin.rushforth at oracle.com>

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1637#pullrequestreview-2446564583

From angorya at openjdk.org  Tue Nov 19 21:57:15 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 19 Nov 2024 21:57:15 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v10]
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: <QkJbdH-k8WHl8d5DHgNA_DFSVL02Hi81pLL5IwsdweI=.d66ea27b-5db5-4afb-828d-f6f397052632@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 24
>      */
>     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 24
>      */
>     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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - coordinates
 - note
 - text layout test
 - text flow test
 - shorter array
 - line spacing
 - 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
 - ... and 22 more: https://git.openjdk.org/jfx/compare/f6c738da...d31eb2b2

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/6776d978..d31eb2b2

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

  Stats: 12762 lines in 300 files changed: 4872 ins; 5866 del; 2024 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 kcr at openjdk.org  Tue Nov 19 23:02:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Nov 2024 23:02:11 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v45]
In-Reply-To: <mobHzpOZD1lKIu8tFzfrnvUrB7OTHt335OgfPbIbMN0=.af5ab377-383f-40ad-85eb-a405f1c2f895@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <mobHzpOZD1lKIu8tFzfrnvUrB7OTHt335OgfPbIbMN0=.af5ab377-383f-40ad-85eb-a405f1c2f895@github.com>
Message-ID: <ZIaLtX20GBwjAcS3YONJQdMuHK1xkhNxC8iC78SNxEc=.a33175f1-f405-4cec-abb8-70beaed08fc1@github.com>

On Fri, 15 Nov 2024 17:36:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - save as
>  - removed function handler
>  - removed add handler last
>  - use focus traversal api
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - settings
>  - comment
>  - review comments
>  - ... and 53 more: https://git.openjdk.org/jfx/compare/dd600658...52a7dba1

Here are my first batch of comments on the "InputMap (Incubator)" API.

1. `BehaviorBase`: I'm not yet convinced that this should be part of the public API. If it is, it needs a better name; the current name would be suitable for a class that all behaviors are required to extend (analogous to SkinBase, which skins need to extend, because Control takes a SkinBase). This behavior base class is optional and supports `SkinInputMap.Stateful` only.

2. `SkinInputMap.Stateful` / `SkinInputMap.Stateless`: The `.Stateful` and `.Stateless` split doesn't seem like the right level of abstraction; in particular, it doesn't seem like the `.Stateless` class has been fully fleshed out. One thought: Could the `.Stateful` and `.Stateless` classes be unified? They don't seem all that different, and it could clean up the API.

3. Can `SkinInputMap` be installed only on the `Skin` and not on the `Control` (i.e., not in the `InputMap` itself)? There are `SkinInputMap` methods that are now package scope that would need accessors to make this work, but that should not be a concern (they are already internal interfaces in the current proposal and would remain so). Related to this, should `SkinInputMap` and `BehaviorBase` be moved to a separate package, something with "skin" in the name? Both of these suggestions would help with separation of concerns. These classes are for of developers of custom controls (or custom skins / behaviors for existing controls) not app developers using `InputMap`.

SUGGESTION: Given the above, and since most of the concerns raised about the InputMap API are also around the Behavior and Skins, I recommend that you consider making the Skin / Behavior part of the Input Map incubator module non-public in the first version? You could make it public in v2, which would give more time to address these and other issues.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2486921662

From angorya at openjdk.org  Tue Nov 19 23:35:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 19 Nov 2024 23:35:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v46]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <QIC_ztfhQjEndhpwex9bo7GdTA6LQII-LBc060nLrFw=.335f6f53-7c02-464f-9faf-b16e0d6833f3@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - hide skin input map
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - save as
 - removed function handler
 - removed add handler last
 - use focus traversal api
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - settings
 - ... and 55 more: https://git.openjdk.org/jfx/compare/7d1b2c3e...018bc86e

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=45
  Stats: 40145 lines in 210 files changed: 40131 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From angorya at openjdk.org  Tue Nov 19 23:35:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 19 Nov 2024 23:35:39 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v45]
In-Reply-To: <mobHzpOZD1lKIu8tFzfrnvUrB7OTHt335OgfPbIbMN0=.af5ab377-383f-40ad-85eb-a405f1c2f895@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <mobHzpOZD1lKIu8tFzfrnvUrB7OTHt335OgfPbIbMN0=.af5ab377-383f-40ad-85eb-a405f1c2f895@github.com>
Message-ID: <bBsyhs2xu3wpEAWj4TtogbO208KCnlfZgROC7XR1hQo=.d1e4bfa4-ee58-4d30-b620-4ee9941e5b16@github.com>

On Fri, 15 Nov 2024 17:36:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:
> 
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - save as
>  - removed function handler
>  - removed add handler last
>  - use focus traversal api
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - settings
>  - comment
>  - review comments
>  - ... and 53 more: https://git.openjdk.org/jfx/compare/dd600658...52a7dba1

> SUGGESTION ... Skin / Behavior part of the Input Map incubator module non-public

Good idea, thanks!

These classes were designed to help the custom controls' developers, and are not essential for the purpose of collecting feedback from the rich text application developers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2486976817

From arapte at openjdk.org  Wed Nov 20 00:33:35 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 20 Nov 2024 00:33:35 GMT
Subject: Integrated: 8343196: Add build property to identify experimental
 builds of JavaFX
In-Reply-To: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@github.com>
Message-ID: <LszuQ2N8JdPGn9BvUqnrt1-4OoKjlBwUAhBe9-Bs98s=.e2d19c2a-d181-4bdd-bfa7-3ec3066fe358@github.com>

On Thu, 14 Nov 2024 12:01:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Introduce a new build property `jfx.experimental.release.suffix` to be used for the early access builds of an under development feature in JavaFX.
> This property would be set to a value ONLY in a branch specific to an experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
> For example:
> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The javafx.version for the early access build generated from that branch would be `24-metal`.
> 
> And it would always be empty for master branch in both main jfx repo and in jfx-sandbox repo.
> This change has no effect on a regular developer build from master branch.

This pull request has now been integrated.

Changeset: 35ff442f
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/35ff442f0c40d7bf1aa28e647cbab26c73227592
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8343196: Add build property to identify experimental builds of JavaFX

Reviewed-by: kcr, jvos

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

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

From kcr at openjdk.org  Wed Nov 20 00:41:26 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 00:41:26 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v46]
In-Reply-To: <QIC_ztfhQjEndhpwex9bo7GdTA6LQII-LBc060nLrFw=.335f6f53-7c02-464f-9faf-b16e0d6833f3@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <QIC_ztfhQjEndhpwex9bo7GdTA6LQII-LBc060nLrFw=.335f6f53-7c02-464f-9faf-b16e0d6833f3@github.com>
Message-ID: <V_CjpjyZCqH1AIXtf7-KjbYJdCC4HjAfBVTTUDqoGW0=.dcc20dfe-2275-40d2-ba4c-1bed053762da@github.com>

On Tue, 19 Nov 2024 23:35:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
> 
>  - hide skin input map
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - save as
>  - removed function handler
>  - removed add handler last
>  - use focus traversal api
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - settings
>  - ... and 55 more: https://git.openjdk.org/jfx/compare/7d1b2c3e...018bc86e

Thanks, I'll review the now-much-smaller public API surface of the input map module.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2487052988

From kcr at openjdk.org  Wed Nov 20 00:49:25 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 00:49:25 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v3]
In-Reply-To: <Pvqec35vK7wwT-HLIZo58y8MoT6LJY5659Zlsi_ibYQ=.2180bbcf-5203-4568-9dde-7f3a718b3c92@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
 <Pvqec35vK7wwT-HLIZo58y8MoT6LJY5659Zlsi_ibYQ=.2180bbcf-5203-4568-9dde-7f3a718b3c92@github.com>
Message-ID: <A8S9RN9rjHgaPBiOZAh9eZkc_K-K-TtLcw0GpQUELYo=.ac85a72d-3b9c-4d64-92a5-2dbaf99396e4@github.com>

On Tue, 19 Nov 2024 11:45:57 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Code-wise looks good. I wanted to verify the patch on my end, but I need to get up to speed with JDK repos to build it with your other change. I'll try to get it approved tomorrow, assuming it all works well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2487068184

From kcr at openjdk.org  Wed Nov 20 00:49:26 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 00:49:26 GMT
Subject: Withdrawn: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session
In-Reply-To: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
Message-ID: <thkrbjd0w23D9HAu3obh7qzbz8F0qoWmhsGg5q2lfxw=.0286f85a-7e09-4a36-ba8f-9b8ca272fd38@github.com>

On Fri, 15 Nov 2024 01:47:40 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
> 
> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
> 
> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
> 
> ---- 
> 
> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
> This is to reduce overhead in case of frequent consecutive screen captures.
> 
> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
> 
> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
> 
> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
> 
> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
> 
> ----
> 
> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
> But if the JDK and JavaFX have the fixes, everything works fine.
> Testing in other different scenarios also looks good.

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Wed Nov 20 00:56:20 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 00:56:20 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v3]
In-Reply-To: <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <2Ea3UT26R2UXwAxAdvEATu17IoYP6Iva4WcTfkiam6Q=.fee7597a-e3f6-46c9-88c5-4c2253396037@github.com>
Message-ID: <E32zle9hX4pHf3b6jgD_V8n4Q_ZTP5koL1iSoQXUUhc=.c6468dd7-4b81-451d-a550-c524d5da463e@github.com>

On Sat, 16 Nov 2024 20:19:06 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - formatting
>  - ParameterizedTest

Hmm. I don't what happened. I didn't mean to close this. Reopening it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2487076661

From prr at openjdk.org  Wed Nov 20 01:10:21 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Nov 2024 01:10:21 GMT
Subject: RFR: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <c5f9-NOZPysewn-iQZnvZnthzGYvkWGLLTFjvqr8VLw=.538ee8d2-62b4-404b-9926-2fe9d27e8b18@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1643#pullrequestreview-2447122306

From azvegint at openjdk.org  Wed Nov 20 03:00:36 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 20 Nov 2024 03:00:36 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v4]
In-Reply-To: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
Message-ID: <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>

> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
> 
> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
> 
> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
> 
> ---- 
> 
> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
> This is to reduce overhead in case of frequent consecutive screen captures.
> 
> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
> 
> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
> 
> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
> 
> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
> 
> ----
> 
> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
> But if the JDK and JavaFX have the fixes, everything works fine.
> Testing in other different scenarios also looks good.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  improve crash detection

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1639/files
  - new: https://git.openjdk.org/jfx/pull/1639/files/a2319785..5ebf1758

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

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

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

From azvegint at openjdk.org  Wed Nov 20 03:05:22 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 20 Nov 2024 03:05:22 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v4]
In-Reply-To: <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
Message-ID: <VAdkFuexZGpdZ8Ze8nawgTxJrd78EPLofZSq64ye6o8=.216fc543-8069-407a-90b9-86f30f69b9cf@github.com>

On Wed, 20 Nov 2024 03:00:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve crash detection

tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 140:

> 138:         DELAY_BEFORE_SESSION_CLOSE + 25
> 139:     })
> 140:     public void testCrash(int delay) throws Exception {

Updated the test to better detect the crash:

The delay between `awtPixel()` and `awtPixelOnFxThread();` was too small.
Since they share the same screencast session, it may not have been closed and reused with the second call.

Now it should cover both scenarios I wanted to test

1. close JDK session while FX session is active, close FX session after
2. close FX session while JDK session is active. close JDK session after

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1639#discussion_r1849435461

From kcr at openjdk.org  Wed Nov 20 12:58:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 12:58:35 GMT
Subject: Integrated: 8344443: Deprecate FXPermission for removal
In-Reply-To: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
References: <MEa5DksTTNysDeq1r1dnEhPWt4k6xH_6LinG077qIMc=.746424a8-44ab-4e85-8d33-9bd6987d342e@github.com>
Message-ID: <UB730n5YT_LzxrJWXxMsWxZg-M3DN2n72UBO5jltJNk=.23539a9f-c909-4898-9483-510ea5e68742@github.com>

On Mon, 18 Nov 2024 18:59:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR deprecates the FXPermission class for removal. The intent is to deprecate it in 24 and remove it in 26.
> 
> This class no longer does anything. Now that we have finished the post-SM removal cleanup, there are no remaining references FXPermission in JavaFX.

This pull request has now been integrated.

Changeset: 3a8a5598
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3a8a5598fa3e4fa326b1332c0bba6905183348f5
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8344443: Deprecate FXPermission for removal

Reviewed-by: angorya, arapte, prr

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

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

From lkostyra at openjdk.org  Wed Nov 20 13:20:24 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 20 Nov 2024 13:20:24 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v4]
In-Reply-To: <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
Message-ID: <sYBoDdFGHj9_Yr4ttGSEz6y6wlLS4Fec_YAJzcPg59Q=.ba6a0742-55d4-44b8-87db-f4cda5747074@github.com>

On Wed, 20 Nov 2024 03:00:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve crash detection

Looks good

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1639#pullrequestreview-2448594854

From nlisker at openjdk.org  Wed Nov 20 15:18:20 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 20 Nov 2024 15:18:20 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
In-Reply-To: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
References: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
Message-ID: <iNzaa-xV3cgpFTaDqOZHUUry5fV9m079nbH6m0m9Kh0=.5a584bc0-20cd-4b79-88ae-b14ba0f86b43@github.com>

On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A batch of typo and grammar fixes that were found by the spellchecker.
> 
> Integration can wait until RDP 1/2.

I found some spellchecker to which you give a URL and it finds the mistakes. I needed it for something else, but then thought it could be used on the JavaDocs so I gave it a shot.

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

PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2488852379

From kcr at openjdk.org  Wed Nov 20 15:55:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 20 Nov 2024 15:55:37 GMT
Subject: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session [v4]
In-Reply-To: <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
 <EvPIp9fZeWycl0Qj5Ksc5YiktMN9wcPjuPXJiupuKfg=.53efaac2-dc40-4d15-8166-c2f41885a4bd@github.com>
Message-ID: <v-qKfaBLOpMO2TPVcRWW5OvH3-hLmhtFz6M0xT-Qah8=.a442a797-bc05-49a3-b1eb-cd1ecc7957dd@github.com>

On Wed, 20 Nov 2024 03:00:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
>> 
>> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
>> 
>> ---- 
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> ----
>> 
>> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
>> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve crash detection

The updated test now crashes consistently on my Ubuntu 22.04 VM without your fix. It still passes consistently with your fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1639#pullrequestreview-2449041196

From angorya at openjdk.org  Wed Nov 20 17:48:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 20 Nov 2024 17:48:40 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

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

 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - hide skin input map
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - save as
 - removed function handler
 - removed add handler last
 - use focus traversal api
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7

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

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=46
  Stats: 40145 lines in 210 files changed: 40131 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From johan.vos at gluonhq.com  Wed Nov 20 18:59:06 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 20 Nov 2024 19:59:06 +0100
Subject: test SDKs for headless builds
Message-ID: <CABxFH2G4KqpjpeJ49a7xp2fUayxhh48BcXNyA3YNOQgXw1vdyg@mail.gmail.com>

Hi,

Now that JDK-8343196 [1] (Add build property to identify experimental
builds of JavaFX) is integrated, I added a  jfx.experimental.feature.name
property in the headless branch of the sandbox [2] and set that to
"headless"

Based on that commit, we created builds, and the SDKs containing the
headless glass platform are available at those urls:

https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-aarch64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-x86_64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-aarch64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-x86_64_bin-sdk.zip
https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_windows-x86_64_bin-sdk.zip

The system property "javafx.version" returns "24-headless" and
"javafx.runtime.version" returns "24-headless+844-2024-11-20-125652" on my
linux-x86_64.

Especially developers who currently use monocle to do headless work are
recommended to give those test SDKs a try and to report.

Thanks,

- Johan

[1] https://bugs.openjdk.java.net/browse/JDK-8343196
[2] https://github.com/openjdk/jfx-sandbox/commits/johanvos-headless/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241120/b52bff88/attachment-0001.htm>

From michaelstrau2 at gmail.com  Wed Nov 20 22:36:03 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 20 Nov 2024 23:36:03 +0100
Subject: Prioritized event handlers
In-Reply-To: <BYAPR10MB3013A68D7011C923FF8985F0E55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAJEpuXTW48Yu6so-QhBtS24-PYcMsp8egRmPYW3HZGYT1Fc0AA@mail.gmail.com>
 <DM5PR1001MB21720F27F2E229C501239F5CE5DCA@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXRpPD5W6NFNQRJsVeU32UmsrDXtfi23AehKFPsvULfM8w@mail.gmail.com>
 <DM5PR1001MB21720B81E7695223DB8601BFE5A1A@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <BYAPR10MB3013A68D7011C923FF8985F0E55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXR6cz4U7j1jT3rLAKv5thfPwZCf6rkB_Q3do=VneD2VXg@mail.gmail.com>

Hi Andy!

> 1. Does this proposal changes the way events are dispatched with respect to priority?  In other words, does it first go through the list of all handlers registred on the leaf Node (high priority first, then lower, then lowest), then bubble up?  Or do they propagate upwards looking for high priority handlers first, then the process restarts for lower priorities, as I saw in some previous emails?  (I could be mistaken)

I think it would most likely be the latter, i.e. a separate "wave" for
each priority where the event first tunnels down to the target, and
then bubbles back up. The downside of this is the increased
implementation complexity: we probably don't want to increase the
number of events five-fold, especially when most of the time, no one
is listening anyway. So there would have to be quite a bit of
optimization to make this work efficiently.


> 2. Do you propose to abort event dispatching immediately after the event is consumed?  This probably should be mentioned earlier in the Motivation (the problem statement) section.

Yes, once an event is consumed, further dispatching stops immediately.
We also need to fix the bug that is currently in FX where that's not
the case for listeners on the same node.


The rest of the questions are very specific for prioritized event
handlers. But I now think that unconsumed event handlers are a much
simpler solution to the problem, as it solves the same set of problems
that are solved with prioritized event handlers.

From michaelstrau2 at gmail.com  Wed Nov 20 22:41:55 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 20 Nov 2024 23:41:55 +0100
Subject: Focus delegation API
In-Reply-To: <BYAPR10MB3013A4B3062D686CDE6C147EE55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB3013A4B3062D686CDE6C147EE55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXRrQwnS2cVYAPsq5migrWhRVBe97=Z0cPnR3CyGv1XLQQ@mail.gmail.com>

I don't see how these problems are at all related.

My proposal solves the focus delegation problem that is inherent with
composite controls, which is not even addressed by the InputMap
proposal.

It also solves an artifact of the event system, namely that key events
are delivered to the focused node, which cannot simultaneously be the
Spinner and its TextField. The ugly hack to make this work is to
duplicate the event entirely, so that if you'd observe Spinner and
listen for key events, you will see duplicated key presses. This is
also not solved in any meaningful way by InputMap.



On Wed, Nov 13, 2024 at 8:33?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> I feel this is going in a wrong direction: the root cause of the issues we are observing, in my opinion, is that the top-level Control is fighting for control with the inner control, and the inner control's behaves as if it is a top-level control.
>
> What should happen instead is to provide a way for the top-level Control to disable those aspects of the inner control behavior (event handlers, key bindings) that are not needed anymore, and replace them with the new logic.
> Continuing the Spinner example, it is ok for the TextField (Spinner.editor) to receive events, but the handling of certain key combinations should be disabled and instead bubbled up to the Spinner behavior.
>
> I propose to use the InputMap https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md for this purpose.
>
> -andy

From jvos at openjdk.org  Thu Nov 21 10:51:34 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 10:51:34 GMT
Subject: [jfx17u] Integrated: 8318388: Update libxslt to 1.1.39
Message-ID: <48uwfMw3dg32he4F93gNcICpPVEFPO0FWrzslFtBz1I=.cef7adce-9c0b-47f7-9882-b65bd92f0861@github.com>

Hi all,

This pull request contains a backport of commit [09922d5c](https://github.com/openjdk/jfx/commit/09922d5c030aa4d82a477f2c1ca27de052f0543d) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Hima Bindu Meda on 5 Dec 2023 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 09922d5c030aa4d82a477f2c1ca27de052f0543d

Changes: https://git.openjdk.org/jfx17u/pull/210/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=210&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318388
  Stats: 2658 lines in 49 files changed: 1069 ins; 1158 del; 431 mod
  Patch: https://git.openjdk.org/jfx17u/pull/210.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/210/head:pull/210

PR: https://git.openjdk.org/jfx17u/pull/210

From jvos at openjdk.org  Thu Nov 21 10:51:34 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 10:51:34 GMT
Subject: [jfx17u] Integrated: 8318388: Update libxslt to 1.1.39
In-Reply-To: <48uwfMw3dg32he4F93gNcICpPVEFPO0FWrzslFtBz1I=.cef7adce-9c0b-47f7-9882-b65bd92f0861@github.com>
References: <48uwfMw3dg32he4F93gNcICpPVEFPO0FWrzslFtBz1I=.cef7adce-9c0b-47f7-9882-b65bd92f0861@github.com>
Message-ID: <yj_OAN7QJoFKioz6qCKWr-TIaj3gUD2HCgGZ5CiUk8c=.6a5c6172-12c5-4ff3-87c7-73aab6f8938e@github.com>

On Thu, 21 Nov 2024 10:45:20 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [09922d5c](https://github.com/openjdk/jfx/commit/09922d5c030aa4d82a477f2c1ca27de052f0543d) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 5 Dec 2023 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ee285e3a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/ee285e3a5d438a3219fd5e7737c88a3edd701b01
Stats:     2658 lines in 49 files changed: 1069 ins; 1158 del; 431 mod

8318388: Update libxslt to 1.1.39

Backport-of: 09922d5c030aa4d82a477f2c1ca27de052f0543d

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

PR: https://git.openjdk.org/jfx17u/pull/210

From jvos at openjdk.org  Thu Nov 21 10:52:00 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 10:52:00 GMT
Subject: [jfx21u] Integrated: 8318388: Update libxslt to 1.1.39
Message-ID: <mF3Y3mFcPlzlbzZs_R76oHpI5e0ArUNxLlB7GLyaUSI=.86077d5b-53d4-403d-8b8d-39cd1a2d42a4@github.com>

Hi all,

This pull request contains a backport of commit 09922d5c from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 5 Dec 2023 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 09922d5c030aa4d82a477f2c1ca27de052f0543d

Changes: https://git.openjdk.org/jfx21u/pull/75/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=75&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318388
  Stats: 2658 lines in 49 files changed: 1069 ins; 1158 del; 431 mod
  Patch: https://git.openjdk.org/jfx21u/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/75/head:pull/75

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

From jvos at openjdk.org  Thu Nov 21 10:52:01 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 10:52:01 GMT
Subject: [jfx21u] Integrated: 8318388: Update libxslt to 1.1.39
In-Reply-To: <mF3Y3mFcPlzlbzZs_R76oHpI5e0ArUNxLlB7GLyaUSI=.86077d5b-53d4-403d-8b8d-39cd1a2d42a4@github.com>
References: <mF3Y3mFcPlzlbzZs_R76oHpI5e0ArUNxLlB7GLyaUSI=.86077d5b-53d4-403d-8b8d-39cd1a2d42a4@github.com>
Message-ID: <a_LFz7-Ogba1WqJb51BG6CxhjM8fMSrtqa_Ws0iVus0=.87a92197-1602-44c2-9863-9ba1f5174b7e@github.com>

On Thu, 21 Nov 2024 10:43:20 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 09922d5c from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 5 Dec 2023 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ed66e508
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/ed66e508c0a81128eab5ccede59ea12defdaf8b5
Stats:     2658 lines in 49 files changed: 1069 ins; 1158 del; 431 mod

8318388: Update libxslt to 1.1.39

Backport-of: 09922d5c030aa4d82a477f2c1ca27de052f0543d

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

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

From jvos at openjdk.org  Thu Nov 21 10:55:25 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 10:55:25 GMT
Subject: [jfx21u] Integrated: 8331616: ChangeListener is not triggered when the
 InvalidationListener is removed
In-Reply-To: <iHqDUXBJwrQMtbzvuU9ZC2q6lyMm_UKsUZhgcXrv5n8=.c7225c9e-b0c9-4b0e-a619-e4392a0263ac@github.com>
References: <iHqDUXBJwrQMtbzvuU9ZC2q6lyMm_UKsUZhgcXrv5n8=.c7225c9e-b0c9-4b0e-a619-e4392a0263ac@github.com>
Message-ID: <u0NXVVLemfrMQ_Eo8-AwtxOxeYAMcKKMIvMAEywIXLU=.596f5cac-bb4a-46aa-ab2d-b2d0a1b443a1@github.com>

On Tue, 29 Oct 2024 13:39:15 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8331616: ChangeListener is not triggered when the InvalidationListener is removed

This pull request has now been integrated.

Changeset: 8ca011cd
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/8ca011cdae18e0dfe6f2577419c0c7b1ee436124
Stats:     69 lines in 2 files changed: 66 ins; 2 del; 1 mod

8331616: ChangeListener is not triggered when the InvalidationListener is removed

Reviewed-by: jhendrikx
Backport-of: 35880cec5a998598c64eecbc7b3ae56b6ee3a6d8

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

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

From jvos at openjdk.org  Thu Nov 21 11:05:57 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:05:57 GMT
Subject: [jfx17u] Integrated: 8336941: Update libxslt to 1.1.42
Message-ID: <IU8Ff9pfmMCUmDgXX8qc8TEoW3Ay6gF0RCFP8viI59c=.fb64ece0-790c-45f3-a19b-680bd3bd90c7@github.com>

Hi all,

This pull request contains a backport of commit dc8f607e from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 14 Aug 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport dc8f607e4ce95e348bb812a1c942e4321c00f0f8

Changes: https://git.openjdk.org/jfx17u/pull/211/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=211&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336941
  Stats: 478 lines in 19 files changed: 111 ins; 316 del; 51 mod
  Patch: https://git.openjdk.org/jfx17u/pull/211.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/211/head:pull/211

PR: https://git.openjdk.org/jfx17u/pull/211

From jvos at openjdk.org  Thu Nov 21 11:05:57 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:05:57 GMT
Subject: [jfx17u] Integrated: 8336941: Update libxslt to 1.1.42
In-Reply-To: <IU8Ff9pfmMCUmDgXX8qc8TEoW3Ay6gF0RCFP8viI59c=.fb64ece0-790c-45f3-a19b-680bd3bd90c7@github.com>
References: <IU8Ff9pfmMCUmDgXX8qc8TEoW3Ay6gF0RCFP8viI59c=.fb64ece0-790c-45f3-a19b-680bd3bd90c7@github.com>
Message-ID: <6Eyp7D_1_NTWXqQbVUpvEKn1EqBCNiWyEc03zguHIL8=.2836d079-5644-4ae9-a113-b950d126587e@github.com>

On Thu, 21 Nov 2024 10:56:24 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit dc8f607e from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 14 Aug 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 32a059aa
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/32a059aa917b6cbac55420ba78a6004bcd19e675
Stats:     478 lines in 19 files changed: 111 ins; 316 del; 51 mod

8336941: Update libxslt to 1.1.42

Backport-of: dc8f607e4ce95e348bb812a1c942e4321c00f0f8

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

PR: https://git.openjdk.org/jfx17u/pull/211

From jvos at openjdk.org  Thu Nov 21 11:06:03 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:06:03 GMT
Subject: [jfx21u] RFR: 8336941: Update libxslt to 1.1.42
Message-ID: <yp9k92vGAIgmifLcnBwtCnFlvqbzlLf1qhf6by9NaRc=.ef39b351-87f7-44f5-9eca-679ea43630ce@github.com>

Hi all,

This pull request contains a backport of commit dc8f607e from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 14 Aug 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport dc8f607e4ce95e348bb812a1c942e4321c00f0f8

Changes: https://git.openjdk.org/jfx21u/pull/76/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=76&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336941
  Stats: 478 lines in 19 files changed: 111 ins; 316 del; 51 mod
  Patch: https://git.openjdk.org/jfx21u/pull/76.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/76/head:pull/76

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

From jvos at openjdk.org  Thu Nov 21 11:14:26 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:14:26 GMT
Subject: [jfx21u] Integrated: 8336941: Update libxslt to 1.1.42
In-Reply-To: <yp9k92vGAIgmifLcnBwtCnFlvqbzlLf1qhf6by9NaRc=.ef39b351-87f7-44f5-9eca-679ea43630ce@github.com>
References: <yp9k92vGAIgmifLcnBwtCnFlvqbzlLf1qhf6by9NaRc=.ef39b351-87f7-44f5-9eca-679ea43630ce@github.com>
Message-ID: <Os1s-PBaWVesIdtS6QTduo0fmg3XgXzRy1Zh7Pgm4Tw=.80a635c2-8129-492c-9ff2-3e62e5dbc38c@github.com>

On Thu, 21 Nov 2024 11:00:44 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit dc8f607e from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 14 Aug 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ad149f35
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/ad149f354789997c08bfe2b18c5edc1bf81c1d3b
Stats:     478 lines in 19 files changed: 111 ins; 316 del; 51 mod

8336941: Update libxslt to 1.1.42

Backport-of: dc8f607e4ce95e348bb812a1c942e4321c00f0f8

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

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

From jvos at openjdk.org  Thu Nov 21 11:29:54 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:29:54 GMT
Subject: [jfx21u] RFR: 8336798: DRT test cssrounding.html test for linear
 layout fails with WebKit 619.1
Message-ID: <DtJu9UCJPhsy6op2YyigmgkSpx75VRFbfpGB4UoIj2g=.a380dd51-52fb-4b33-a25c-b377f533d10d@github.com>

Hi all,

This pull request contains a backport of commit 06ac1678 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 22 Jul 2024 and was reviewed by Hima Bindu Meda and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 06ac16789f071ec6aca55697c139789ca3218c0d

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

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

From jvos at openjdk.org  Thu Nov 21 11:31:00 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:31:00 GMT
Subject: [jfx17u] RFR: 8336798: DRT test cssrounding.html test for linear
 layout fails with WebKit 619.1
Message-ID: <hYquwMkSKRxBkWoFdIuD4tTj8BYOf9na1wS2JeMLmCQ=.c209bdea-993d-4bf5-be69-41829c40d852@github.com>

Hi all,

This pull request contains a backport of commit 06ac1678 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 22 Jul 2024 and was reviewed by Hima Bindu Meda and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 06ac16789f071ec6aca55697c139789ca3218c0d

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

PR: https://git.openjdk.org/jfx17u/pull/212

From jvos at openjdk.org  Thu Nov 21 11:37:50 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:37:50 GMT
Subject: [jfx21u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
Message-ID: <DHUyliSCkDPL_joUoUW47r2P0FKcknfciDaB9X0cB98=.3ae5c278-5486-4ec2-87bd-487264b0c59c@github.com>

Hi all,

This pull request contains a backport of commit 67ac9d78 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 21 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

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

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

From jvos at openjdk.org  Thu Nov 21 11:37:50 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:37:50 GMT
Subject: [jfx21u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
In-Reply-To: <DHUyliSCkDPL_joUoUW47r2P0FKcknfciDaB9X0cB98=.3ae5c278-5486-4ec2-87bd-487264b0c59c@github.com>
References: <DHUyliSCkDPL_joUoUW47r2P0FKcknfciDaB9X0cB98=.3ae5c278-5486-4ec2-87bd-487264b0c59c@github.com>
Message-ID: <VshNJ_MP8Co1cHH14OsYjGGFKM7fgyz-MdcXtoeuzp8=.19c0c0b8-12d4-457e-b7b7-2a7b4cfdff3e@github.com>

On Thu, 21 Nov 2024 11:31:19 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 67ac9d78 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 21 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 226e8aed
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/226e8aed6767d1aa6e64db7f5683ddbfb4f6a64a
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8338306: WebView Drag and Drop fails with WebKit 619.1

Backport-of: 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

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

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

From jvos at openjdk.org  Thu Nov 21 11:38:31 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:38:31 GMT
Subject: [jfx17u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
Message-ID: <MF9Ipc3Te4B3jCaUiaBasHH5mALEuagZ5Z_BDuzghbs=.b53fc76d-0f51-4e21-b775-9eab67ccefd9@github.com>

Hi all,

This pull request contains a backport of commit 67ac9d78 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 21 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

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

PR: https://git.openjdk.org/jfx17u/pull/213

From jvos at openjdk.org  Thu Nov 21 11:38:31 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 11:38:31 GMT
Subject: [jfx17u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
In-Reply-To: <MF9Ipc3Te4B3jCaUiaBasHH5mALEuagZ5Z_BDuzghbs=.b53fc76d-0f51-4e21-b775-9eab67ccefd9@github.com>
References: <MF9Ipc3Te4B3jCaUiaBasHH5mALEuagZ5Z_BDuzghbs=.b53fc76d-0f51-4e21-b775-9eab67ccefd9@github.com>
Message-ID: <zvqrGCdABA7Lsx8cd8UgZVe2L79e7RlCkf8EqFg9dqo=.8c8e61d1-ec18-41ed-8881-4b482461a0d3@github.com>

On Thu, 21 Nov 2024 11:30:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 67ac9d78 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 21 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 1d216e47
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/1d216e474e47fbfe2527956c40848dc9ef305fe1
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8338306: WebView Drag and Drop fails with WebKit 619.1

Backport-of: 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

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

PR: https://git.openjdk.org/jfx17u/pull/213

From craigraw at gmail.com  Thu Nov 21 12:11:03 2024
From: craigraw at gmail.com (Craig Raw)
Date: Thu, 21 Nov 2024 14:11:03 +0200
Subject: test SDKs for headless builds
In-Reply-To: <CABxFH2G4KqpjpeJ49a7xp2fUayxhh48BcXNyA3YNOQgXw1vdyg@mail.gmail.com>
References: <CABxFH2G4KqpjpeJ49a7xp2fUayxhh48BcXNyA3YNOQgXw1vdyg@mail.gmail.com>
Message-ID: <CAPR5oBPpVqkgS1LXRS5QDZDNObBPbPiH6vH2yrj7Ao4j3DYtEQ@mail.gmail.com>

Thanks Johan, great to see this moving forward.

I tested the mac-aarch64 and linux-x86_64 SDKs, and had no problems when
running the application using a Gradle build.

When I jpackaged the application however, I got the following on launch.
I'm a little uncertain if there was anything else I was doing when this
worked in April, but I am setting -Dglass.platform=Headless as a JVM arg.

Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing
QuantumRenderer: no suitable pipeline found
at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumToolkit.init(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.tk.Toolkit.getToolkit(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.application.PlatformImpl.startup(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.application.PlatformImpl.startup(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.startToolkit(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$0(Unknown
Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer:
no suitable pipeline found
at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(Unknown
Source)
at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(Unknown
Source)
... 1 more

Craig


On Wed, Nov 20, 2024 at 8:59?PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> Now that JDK-8343196 [1] (Add build property to identify experimental
> builds of JavaFX) is integrated, I added a  jfx.experimental.feature.name
> property in the headless branch of the sandbox [2] and set that to
> "headless"
>
> Based on that commit, we created builds, and the SDKs containing the
> headless glass platform are available at those urls:
>
>
> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-aarch64_bin-sdk.zip
>
> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-x86_64_bin-sdk.zip
>
> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-aarch64_bin-sdk.zip
>
> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-x86_64_bin-sdk.zip
>
> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_windows-x86_64_bin-sdk.zip
>
> The system property "javafx.version" returns "24-headless" and
> "javafx.runtime.version" returns "24-headless+844-2024-11-20-125652" on my
> linux-x86_64.
>
> Especially developers who currently use monocle to do headless work are
> recommended to give those test SDKs a try and to report.
>
> Thanks,
>
> - Johan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8343196
> [2] https://github.com/openjdk/jfx-sandbox/commits/johanvos-headless/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241121/ed22615a/attachment.htm>

From jvos at openjdk.org  Thu Nov 21 12:18:32 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:18:32 GMT
Subject: [jfx21u] RFR: 8338307: Additional WebKit 619.1 fixes from WebKitGTK
 2.44.3
Message-ID: <hddX8MCE8JEDuvFy7pu61Qryu7mnrJavZDapfJzMMSs=.cf20df73-8c5c-442d-9c14-a81a11c40658@github.com>

Hi all,

This pull request contains a backport of commit aa52f7ef from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 23 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport aa52f7efc370a4c55ff7a05a6903988871436d64

Changes: https://git.openjdk.org/jfx21u/pull/79/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=79&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338307
  Stats: 1276 lines in 181 files changed: 721 ins; 113 del; 442 mod
  Patch: https://git.openjdk.org/jfx21u/pull/79.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/79/head:pull/79

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

From jvos at openjdk.org  Thu Nov 21 12:20:00 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:20:00 GMT
Subject: [jfx17u] RFR: 8338307: Additional WebKit 619.1 fixes from WebKitGTK
 2.44.3
Message-ID: <zcZTiIsBtAcuhuVL1Sunl79ucmra6RI77wWPm1zzJFE=.9501beb2-4f5d-47a9-bba4-2b397fa75527@github.com>

Hi all,

This pull request contains a backport of commit aa52f7ef from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 23 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport aa52f7efc370a4c55ff7a05a6903988871436d64

Changes: https://git.openjdk.org/jfx17u/pull/214/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=214&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338307
  Stats: 1276 lines in 181 files changed: 721 ins; 113 del; 442 mod
  Patch: https://git.openjdk.org/jfx17u/pull/214.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/214/head:pull/214

PR: https://git.openjdk.org/jfx17u/pull/214

From jvos at openjdk.org  Thu Nov 21 12:39:29 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:39:29 GMT
Subject: [jfx17u] Integrated: 8338307: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.3
In-Reply-To: <zcZTiIsBtAcuhuVL1Sunl79ucmra6RI77wWPm1zzJFE=.9501beb2-4f5d-47a9-bba4-2b397fa75527@github.com>
References: <zcZTiIsBtAcuhuVL1Sunl79ucmra6RI77wWPm1zzJFE=.9501beb2-4f5d-47a9-bba4-2b397fa75527@github.com>
Message-ID: <nSfxZXQr5yz0RROFZLQcNNYrsXDOqUzJrekk27pavzU=.209039ea-972d-4e43-acbd-2db950a353be@github.com>

On Thu, 21 Nov 2024 12:14:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit aa52f7ef from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 23 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 7e813a75
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/7e813a755fdbda4d592caf85f6895c000894a684
Stats:     1276 lines in 181 files changed: 721 ins; 113 del; 442 mod

8338307: Additional WebKit 619.1 fixes from WebKitGTK 2.44.3

Backport-of: aa52f7efc370a4c55ff7a05a6903988871436d64

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

PR: https://git.openjdk.org/jfx17u/pull/214

From jvos at openjdk.org  Thu Nov 21 12:40:21 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:40:21 GMT
Subject: [jfx21u] Integrated: 8338307: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.3
In-Reply-To: <hddX8MCE8JEDuvFy7pu61Qryu7mnrJavZDapfJzMMSs=.cf20df73-8c5c-442d-9c14-a81a11c40658@github.com>
References: <hddX8MCE8JEDuvFy7pu61Qryu7mnrJavZDapfJzMMSs=.cf20df73-8c5c-442d-9c14-a81a11c40658@github.com>
Message-ID: <CmhYhXZZ_inl1SoWel1hFQv_i4fU7fnXBoFODrACxRE=.66a45429-a36f-4596-b166-ec15b408af4f@github.com>

On Thu, 21 Nov 2024 12:14:08 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit aa52f7ef from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 23 Aug 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 049893d3
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/049893d3eb054b941942705405ba1dc9b58f31f4
Stats:     1276 lines in 181 files changed: 721 ins; 113 del; 442 mod

8338307: Additional WebKit 619.1 fixes from WebKitGTK 2.44.3

Backport-of: aa52f7efc370a4c55ff7a05a6903988871436d64

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

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

From jvos at openjdk.org  Thu Nov 21 12:46:23 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:46:23 GMT
Subject: [jfx17u] Integrated: 8336798: DRT test cssrounding.html test for
 linear layout fails with WebKit 619.1
In-Reply-To: <hYquwMkSKRxBkWoFdIuD4tTj8BYOf9na1wS2JeMLmCQ=.c209bdea-993d-4bf5-be69-41829c40d852@github.com>
References: <hYquwMkSKRxBkWoFdIuD4tTj8BYOf9na1wS2JeMLmCQ=.c209bdea-993d-4bf5-be69-41829c40d852@github.com>
Message-ID: <Tg6NHxiRKJLAWK_f3VlCqX2Wy9zpVeLS9IN0Uzijl-k=.883c0c0f-2d53-4236-a820-aed9a28dfebe@github.com>

On Thu, 21 Nov 2024 11:24:30 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 06ac1678 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 22 Jul 2024 and was reviewed by Hima Bindu Meda and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 49a2f3eb
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/49a2f3eb1234898c09271e1d6eb3624726f25e2d
Stats:     173 lines in 2 files changed: 172 ins; 0 del; 1 mod

8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1

Backport-of: 06ac16789f071ec6aca55697c139789ca3218c0d

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

PR: https://git.openjdk.org/jfx17u/pull/212

From jvos at openjdk.org  Thu Nov 21 12:47:32 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:47:32 GMT
Subject: [jfx21u] Integrated: 8336798: DRT test cssrounding.html test for
 linear layout fails with WebKit 619.1
In-Reply-To: <DtJu9UCJPhsy6op2YyigmgkSpx75VRFbfpGB4UoIj2g=.a380dd51-52fb-4b33-a25c-b377f533d10d@github.com>
References: <DtJu9UCJPhsy6op2YyigmgkSpx75VRFbfpGB4UoIj2g=.a380dd51-52fb-4b33-a25c-b377f533d10d@github.com>
Message-ID: <XQ5ml5492Zt2BcpDA1-jgtmeQaFdItLVzhwILE7yZZU=.31682495-5592-4d88-9e18-3554467d2c5a@github.com>

On Thu, 21 Nov 2024 11:24:42 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 06ac1678 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 22 Jul 2024 and was reviewed by Hima Bindu Meda and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b7cd0d9a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/b7cd0d9a2a757acd4945f9440536bb7a4778a707
Stats:     173 lines in 2 files changed: 172 ins; 0 del; 1 mod

8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1

Backport-of: 06ac16789f071ec6aca55697c139789ca3218c0d

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

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

From jvos at openjdk.org  Thu Nov 21 12:50:55 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:50:55 GMT
Subject: [jfx21u] Integrated: 8337481: File API: file.name contains path
 instead of name
Message-ID: <Ogk3tOouZFsuT2bWAO8h5G3CBTRvV89-TXYLs2IiA38=.b07b2877-8769-4b2c-8905-694edf80e964@github.com>

Hi all,

This pull request contains a backport of commit ca70a07b from the openjdk/jfx repository.

The commit being backported was authored by Oliver Schmidtmer on 30 Aug 2024 and was reviewed by Ambarish Rapte and Hima Bindu Meda.

Thanks!

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

Commit messages:
 - Backport ca70a07b3ee712b1d06baf8a3901e6ae96070124

Changes: https://git.openjdk.org/jfx21u/pull/80/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337481
  Stats: 91 lines in 4 files changed: 76 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jfx21u/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/80/head:pull/80

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

From jvos at openjdk.org  Thu Nov 21 12:50:55 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:50:55 GMT
Subject: [jfx21u] Integrated: 8337481: File API: file.name contains path
 instead of name
In-Reply-To: <Ogk3tOouZFsuT2bWAO8h5G3CBTRvV89-TXYLs2IiA38=.b07b2877-8769-4b2c-8905-694edf80e964@github.com>
References: <Ogk3tOouZFsuT2bWAO8h5G3CBTRvV89-TXYLs2IiA38=.b07b2877-8769-4b2c-8905-694edf80e964@github.com>
Message-ID: <Xm5YwcO2q7X4oi0DRcbBXfhJzbryAL7UR0xIjVmLueE=.a26d78b4-cdd5-421a-a293-af6659838b8b@github.com>

On Thu, 21 Nov 2024 12:43:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit ca70a07b from the openjdk/jfx repository.
> 
> The commit being backported was authored by Oliver Schmidtmer on 30 Aug 2024 and was reviewed by Ambarish Rapte and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c00126e0
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/c00126e02094df96276d57a8b0b6ad7fcd25b04e
Stats:     91 lines in 4 files changed: 76 ins; 12 del; 3 mod

8337481: File API: file.name contains path instead of name

Backport-of: ca70a07b3ee712b1d06baf8a3901e6ae96070124

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

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

From jvos at openjdk.org  Thu Nov 21 12:54:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:54:41 GMT
Subject: [jfx17u] Integrated: 8337481: File API: file.name contains path
 instead of name
Message-ID: <7s370E13KTPQGKN18KhtyWs48v8cAyYRtP6FsX-XnfM=.19e49fdd-cceb-4ff9-b680-43851a3c34a0@github.com>

Hi all,

This pull request contains a backport of commit ca70a07b from the openjdk/jfx repository.

The commit being backported was authored by Oliver Schmidtmer on 30 Aug 2024 and was reviewed by Ambarish Rapte and Hima Bindu Meda.

Thanks!

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

Commit messages:
 - Backport ca70a07b3ee712b1d06baf8a3901e6ae96070124

Changes: https://git.openjdk.org/jfx17u/pull/215/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337481
  Stats: 91 lines in 4 files changed: 76 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jfx17u/pull/215.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/215/head:pull/215

PR: https://git.openjdk.org/jfx17u/pull/215

From jvos at openjdk.org  Thu Nov 21 12:54:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 12:54:41 GMT
Subject: [jfx17u] Integrated: 8337481: File API: file.name contains path
 instead of name
In-Reply-To: <7s370E13KTPQGKN18KhtyWs48v8cAyYRtP6FsX-XnfM=.19e49fdd-cceb-4ff9-b680-43851a3c34a0@github.com>
References: <7s370E13KTPQGKN18KhtyWs48v8cAyYRtP6FsX-XnfM=.19e49fdd-cceb-4ff9-b680-43851a3c34a0@github.com>
Message-ID: <8k2eDSi-Wf9ZvWm0VA-O1YTRyA9qbCq63t724pKqLUQ=.8cb4da5f-e827-4cae-93de-37500ea31682@github.com>

On Thu, 21 Nov 2024 12:40:43 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit ca70a07b from the openjdk/jfx repository.
> 
> The commit being backported was authored by Oliver Schmidtmer on 30 Aug 2024 and was reviewed by Ambarish Rapte and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ea7574d0
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/ea7574d0f5725c312e5f6a1b03946289cfdac02a
Stats:     91 lines in 4 files changed: 76 ins; 12 del; 3 mod

8337481: File API: file.name contains path instead of name

Backport-of: ca70a07b3ee712b1d06baf8a3901e6ae96070124

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

PR: https://git.openjdk.org/jfx17u/pull/215

From jvos at openjdk.org  Thu Nov 21 18:34:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:34:59 GMT
Subject: [jfx17u] Integrated: 8334124: Rendering issues with CSS "text-shadow"
 in WebView
Message-ID: <Tc-fYj7DadHEW6G3G2Mufi7cB9aUvEtydNZiFrkH6As=.92723399-1292-4a5b-bad1-9c9e29950130@github.com>

Hi all,

This pull request contains a backport of commit e0ceafb7 from the openjdk/jfx repository.

The commit being backported was authored by Oliver Schmidtmer on 1 Sep 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport e0ceafb7dba15b4faa683c336828e79f19a59d30

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

PR: https://git.openjdk.org/jfx17u/pull/216

From jvos at openjdk.org  Thu Nov 21 18:34:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:34:59 GMT
Subject: [jfx17u] Integrated: 8334124: Rendering issues with CSS "text-shadow"
 in WebView
In-Reply-To: <Tc-fYj7DadHEW6G3G2Mufi7cB9aUvEtydNZiFrkH6As=.92723399-1292-4a5b-bad1-9c9e29950130@github.com>
References: <Tc-fYj7DadHEW6G3G2Mufi7cB9aUvEtydNZiFrkH6As=.92723399-1292-4a5b-bad1-9c9e29950130@github.com>
Message-ID: <JcTrqh6kbH0ku6iWqZ65pKaYdfXnNkLA3cEw2W0fEcA=.e8139ed0-6511-41ed-84ef-82b221254f96@github.com>

On Thu, 21 Nov 2024 18:28:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit e0ceafb7 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Oliver Schmidtmer on 1 Sep 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 7472e01b
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/7472e01bd786c1e88e95866276beb11c7832f614
Stats:     84 lines in 2 files changed: 84 ins; 0 del; 0 mod

8334124: Rendering issues with CSS "text-shadow" in WebView

Backport-of: e0ceafb7dba15b4faa683c336828e79f19a59d30

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

PR: https://git.openjdk.org/jfx17u/pull/216

From jvos at openjdk.org  Thu Nov 21 18:36:42 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:36:42 GMT
Subject: [jfx21u] Integrated: 8334124: Rendering issues with CSS "text-shadow"
 in WebView
Message-ID: <XtfP8L_DJdDNEwggVWEKunaNJKrhzIUZugkYJe87Ef8=.dce073ee-585b-4d0f-938d-b07828bb1bd6@github.com>

Hi all,

This pull request contains a backport of commit e0ceafb7 from the openjdk/jfx repository.

The commit being backported was authored by Oliver Schmidtmer on 1 Sep 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport e0ceafb7dba15b4faa683c336828e79f19a59d30

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

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

From jvos at openjdk.org  Thu Nov 21 18:36:43 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:36:43 GMT
Subject: [jfx21u] Integrated: 8334124: Rendering issues with CSS "text-shadow"
 in WebView
In-Reply-To: <XtfP8L_DJdDNEwggVWEKunaNJKrhzIUZugkYJe87Ef8=.dce073ee-585b-4d0f-938d-b07828bb1bd6@github.com>
References: <XtfP8L_DJdDNEwggVWEKunaNJKrhzIUZugkYJe87Ef8=.dce073ee-585b-4d0f-938d-b07828bb1bd6@github.com>
Message-ID: <bwf0OVKTyCVeO94C6s9Fos0XbxfRlNSuwqEPwEpqzJg=.7d849d51-cc9e-46c1-91cf-2474a5805137@github.com>

On Thu, 21 Nov 2024 18:29:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit e0ceafb7 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Oliver Schmidtmer on 1 Sep 2024 and was reviewed by Kevin Rushforth and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 56ad954b
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/56ad954bb8aba8a7b5475d3a708c8c525ede65e6
Stats:     84 lines in 2 files changed: 84 ins; 0 del; 0 mod

8334124: Rendering issues with CSS "text-shadow" in WebView

Backport-of: e0ceafb7dba15b4faa683c336828e79f19a59d30

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

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

From jvos at openjdk.org  Thu Nov 21 18:39:40 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:39:40 GMT
Subject: [jfx21u] RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK
 2.44.4
Message-ID: <rhnEK7Ot1IKtttcfK63EsJs1wq8OOB877H5q-QTR0C0=.0530952e-0074-4648-a869-0e37b1ec6ecb@github.com>

Hi all,

This pull request contains a backport of commit bc5adfa9 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 23 Sep 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport bc5adfa9b6f9180eb32930f61e59fdc46a83cb73

Changes: https://git.openjdk.org/jfx21u/pull/82/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340208
  Stats: 596 lines in 103 files changed: 376 ins; 116 del; 104 mod
  Patch: https://git.openjdk.org/jfx21u/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/82/head:pull/82

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

From jvos at openjdk.org  Thu Nov 21 18:39:45 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:39:45 GMT
Subject: [jfx17u] Integrated: 8340208: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.4
Message-ID: <26k20-0q0QHv9sjdrCVH68IdH5IAbVM3HyKgUPWSh5o=.73ec2561-c77c-400a-98de-8aa76cfbf461@github.com>

Hi all,

This pull request contains a backport of commit bc5adfa9 from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 23 Sep 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport bc5adfa9b6f9180eb32930f61e59fdc46a83cb73

Changes: https://git.openjdk.org/jfx17u/pull/217/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340208
  Stats: 596 lines in 103 files changed: 376 ins; 116 del; 104 mod
  Patch: https://git.openjdk.org/jfx17u/pull/217.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/217/head:pull/217

PR: https://git.openjdk.org/jfx17u/pull/217

From jvos at openjdk.org  Thu Nov 21 18:39:46 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:39:46 GMT
Subject: [jfx17u] Integrated: 8340208: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.4
In-Reply-To: <26k20-0q0QHv9sjdrCVH68IdH5IAbVM3HyKgUPWSh5o=.73ec2561-c77c-400a-98de-8aa76cfbf461@github.com>
References: <26k20-0q0QHv9sjdrCVH68IdH5IAbVM3HyKgUPWSh5o=.73ec2561-c77c-400a-98de-8aa76cfbf461@github.com>
Message-ID: <09UkS-JZhNXsYqqyEfN1mkVNNwlT9GoBr0_QJv0PHNo=.3a3f239c-0794-4717-afcb-98f3d6407959@github.com>

On Thu, 21 Nov 2024 18:33:21 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit bc5adfa9 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 23 Sep 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3cb7301a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/3cb7301a3889ef92ab4582e83e5a1730f425fb66
Stats:     596 lines in 103 files changed: 376 ins; 116 del; 104 mod

8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4

Backport-of: bc5adfa9b6f9180eb32930f61e59fdc46a83cb73

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

PR: https://git.openjdk.org/jfx17u/pull/217

From jvos at openjdk.org  Thu Nov 21 18:42:23 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 18:42:23 GMT
Subject: [jfx21u] Integrated: 8340208: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.4
In-Reply-To: <rhnEK7Ot1IKtttcfK63EsJs1wq8OOB877H5q-QTR0C0=.0530952e-0074-4648-a869-0e37b1ec6ecb@github.com>
References: <rhnEK7Ot1IKtttcfK63EsJs1wq8OOB877H5q-QTR0C0=.0530952e-0074-4648-a869-0e37b1ec6ecb@github.com>
Message-ID: <er7cyshEB5lNf-Jp35wBc1ddkbpVzKRHHldQh6c1YtA=.542b02d9-930f-452e-bfc5-5965b79b4300@github.com>

On Thu, 21 Nov 2024 18:35:11 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit bc5adfa9 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 23 Sep 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 95cd24ee
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/95cd24ee9a322f04566274751b5e942d5e792225
Stats:     596 lines in 103 files changed: 376 ins; 116 del; 104 mod

8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4

Backport-of: bc5adfa9b6f9180eb32930f61e59fdc46a83cb73

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

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

From kcr at openjdk.org  Thu Nov 21 19:37:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 21 Nov 2024 19:37:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
Message-ID: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>

On Wed, 20 Nov 2024 17:48:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - hide skin input map
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - save as
>  - removed function handler
>  - removed add handler last
>  - use focus traversal api
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7

Here are some comments on the slimmed-down Input Map portion of this PR. My main questions are around the handling of platform-specific modifiers in `KeyBinding` -- most of them are macOS vs others. Do we need platform-specific methods or can we use platform-neutral methods that map to the specific key?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/EventCriteria.java line 31:

> 29: 
> 30: /**
> 31:  * This interface enables wider control in specifying conditional matching logic when adding skin/behavior handlers.

Can this interface be hidden as well? It may not need to be in the public API now that SkinInputMap and BehaviorBase aren't.

If it still needs to be part of the public API, it will need a better description. One that answers the questions: What is the purpose of this interface? Who implements it? Who uses it?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/FunctionTag.java line 34:

> 32:  * control's {@link InputMap}.
> 33:  * <h2>Example</h2>
> 34:  * The following example is taken from the {@code TabPane} class:

Minor: I recommend using a pseudo-control or `RichTextArea` as your example, since there aren't any function tags for `TabPane`.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/FunctionTag.java line 51:

> 49: public final class FunctionTag {
> 50:     /** Constructs the function tag. */
> 51:     public FunctionTag() {

Should this be more than a simple "marker" Object with identity, but no state? There is no way to get the information from a particular function tag instance as to what it represents, nor is there a useful "toString()" method. There is also no way to get the set of available FunctionTag objects from the nested <Control>.Tag class. Perhaps we could be informed by the Enum class?

If there was value in doing this, maybe it could be a record?


    public final record FunctionTag(String name) { }


This would be mostly useful for tooling, since most applications aren't likely to need it.

It might be worth noting, even if you prefer not to make this change.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 53:

> 51:  * The {@code InputMap} The InputMap provides an ordered repository of event handlers,
> 52:  * working together with {@link SkinInputMap} supplied by the skin, which
> 53:  * guarantees the order in which handers are invoked.

`SkinInputMap` is not public, so maybe say something like "the input map managed by the Skin" (or similar).

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 60:

> 58:  * The class supports the following scenarios:
> 59:  * <ul>
> 60:  * <li>map a key binding to a function, provided either by the application or the skin

I think you can remove "or the skin" for this version.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 64:

> 62:  * <li>map a new function to an existing key binding
> 63:  * <li>obtain the default function
> 64:  * <li>add an event handler at specific priority (applies to application-defined and skin-defined handlers)

There is no API to control the priority (which is a good thing to have eliminated). I would remove this bullet.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 236:

> 234:     /**
> 235:      * Registers a function for the given key binding.  This mapping will  take precedence
> 236:      * over any such mapping set by the skin.

Maybe "any such mapping set _internally_ by the skin"? Or "the _default_ mapping set by the skin"?

This comment applies here and elsewhere.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 325:

> 323: 
> 324:     /**
> 325:      * Collects all mapped key bindings (set either by the user or the behavior).

I don't think the "or the behavior" part is right (this wouldn't return anything set by the behavior, since that is an implementation detail).

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 36:

> 34: 
> 35: /**
> 36:  * Key binding provides a way to map key event to a hash table key for easy matching.

What, exactly, is the purpose of this class as public API? The above makes it sound like an implementation detail.

Also, what does it provide that KeyMapping doesn't?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 123:

> 121:      * and the {@code alt} key modifier ({@code option} on macOS).
> 122:      * <p>
> 123:      * This method is equivalent to {@link #option(KeyCode)} on macOS.

Then do we need both?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 134:

> 132:     /**
> 133:      * Creates a KeyBinding which corresponds to the key press with the specified {@code KeyCode}
> 134:      * and the {@code ctrl} key modifier ({@code control} on macOS).

I don't see the need for calling out macOS here.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 145:

> 143:     /**
> 144:      * Creates a KeyBinding which corresponds to the key press with the specified {@code KeyCode}
> 145:      * and the {@code shift} + {@code ctrl} key modifier ({@code control} on macOS).

I don't see the need for calling out macOS here.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 163:

> 161:      * @return the KeyBinding, or null
> 162:      */
> 163:     public static KeyBinding option(KeyCode code) {

In the documentation of `alt` you say that it is equivalent to `option` on macOS. So what we have is an `alt` method that works on all platforms and an `option` method that does the same thing as `alt` on macOS and returns `null` on other platforms? This seems like an odd situation. Do we really need the `option` method?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 198:

> 196:      * @return the KeyBinding, or null
> 197:      */
> 198:     public static KeyBinding shiftOption(KeyCode code) {

Is there a `shiftAlt` that would make sense on other platforms? If so, maybe that could supersede this?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 269:

> 267:     /**
> 268:      * Determines whether {@code alt} key is down in this key binding.
> 269:      * @return true if {@code alt} key is down in this key binding

Does this return true if the `option` key is down on macOS?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 343:

> 341:     /**
> 342:      * Creates a {@link Builder} with the specified KeyCode.
> 343:      * @param character the character

Since the type is String what if it is more than one character?

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 375:

> 373:      * @return Builder instance
> 374:      */
> 375:     public static Builder with(KeyCode c) {

This is redundant. We don't need both `builder` and `with` methods that do exactly the same thing.  I recommend removing this one.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 384:

> 382:      * @return Builder instance
> 383:      */
> 384:     public static Builder with(String c) {

This method is redundant -- it's identical to builder(String). I recommend removing it.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/package-info.java line 38:

> 36:  * <li>guarantees priorities between the application and the skin event handlers and key mappings
> 37:  * <li>allows for gradual migration of the existing controls to use the InputMap
> 38:  * <li>supports stateful and stateless (fully static) behavior implementations

This should be removed in this version.

modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/package-info.java line 42:

> 40:  * See
> 41:  * <a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md">Public InputMap Proposal (v3)</a>
> 42:  * for more info.

I don't think we want a pointer to the JEP here, especially since it isn't in a permanent repository. I would include the relevant information, but not the link.

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

PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2449892430
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852720301
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851125949
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851128262
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851104483
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851105523
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851106631
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851111535
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851121542
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852724848
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851134441
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851134610
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851134754
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851136137
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851137520
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851138479
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851139587
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851142008
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851142256
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851122630
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1851123668

From jvos at openjdk.org  Thu Nov 21 20:10:32 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:10:32 GMT
Subject: [jfx21u] Integrated: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
Message-ID: <dvClbFB_U9kXwDzeHqCbmYjR99CYriNSTCZvzJGrJcI=.7f5aab85-1c1b-4247-b3ac-8b029b71b810@github.com>

Hi all,

This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.

Thanks!

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

Commit messages:
 - Backport fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

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

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

From jvos at openjdk.org  Thu Nov 21 20:10:32 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:10:32 GMT
Subject: [jfx21u] Integrated: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
In-Reply-To: <dvClbFB_U9kXwDzeHqCbmYjR99CYriNSTCZvzJGrJcI=.7f5aab85-1c1b-4247-b3ac-8b029b71b810@github.com>
References: <dvClbFB_U9kXwDzeHqCbmYjR99CYriNSTCZvzJGrJcI=.7f5aab85-1c1b-4247-b3ac-8b029b71b810@github.com>
Message-ID: <k1JPQedEgQKibX_KOrvpNEMdhugyuYj8SpB0QmrMc5Q=.6f067f31-1d08-4bf0-992f-b39203c0c9c9@github.com>

On Thu, 21 Nov 2024 20:04:12 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 8fa8dfbf
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/8fa8dfbf62116a9c58605e9d80011526e2654307
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8333374: Cannot invoke "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null

Backport-of: fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

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

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

From jvos at openjdk.org  Thu Nov 21 20:11:00 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:11:00 GMT
Subject: [jfx17u] Integrated: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
Message-ID: <t8bH3lfJKIXq5eGaXh8fgetHpDMWbbI2YKGGaeSQnV4=.9098a3e0-a7f5-4b13-be39-2f055dde6a68@github.com>

Hi all,

This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.

Thanks!

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

Commit messages:
 - Backport fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

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

PR: https://git.openjdk.org/jfx17u/pull/218

From jvos at openjdk.org  Thu Nov 21 20:11:00 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:11:00 GMT
Subject: [jfx17u] Integrated: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
In-Reply-To: <t8bH3lfJKIXq5eGaXh8fgetHpDMWbbI2YKGGaeSQnV4=.9098a3e0-a7f5-4b13-be39-2f055dde6a68@github.com>
References: <t8bH3lfJKIXq5eGaXh8fgetHpDMWbbI2YKGGaeSQnV4=.9098a3e0-a7f5-4b13-be39-2f055dde6a68@github.com>
Message-ID: <MeS6vpi3ARibnUcvGZN0TBeI4JBhT15WNn5msk03BYo=.7c05b5d6-9586-444c-a5da-ce934d265637@github.com>

On Thu, 21 Nov 2024 20:04:16 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 024ae5db
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/024ae5db5c7f9d1aa37072f333db10310f9a01b2
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8333374: Cannot invoke "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null

Backport-of: fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

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

PR: https://git.openjdk.org/jfx17u/pull/218

From jvos at openjdk.org  Thu Nov 21 20:15:40 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:15:40 GMT
Subject: [jfx17u] Integrated: 8341920: Intermittent WebKit build failure on
 Windows generating PDB files in 619.1
Message-ID: <fVkF9_eOnmTYeaqGu3WPZr_VDE26mwFXWlMkHCTgFf0=.57b1cbf1-feba-477c-b556-160d000f184d@github.com>

Hi all,

This pull request contains a backport of commit [0cafd801](https://github.com/openjdk/jfx/commit/0cafd8011b218162259b81872b1672a1a0649eef) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Hima Bindu Meda on 14 Oct 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 0cafd8011b218162259b81872b1672a1a0649eef

Changes: https://git.openjdk.org/jfx17u/pull/219/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341920
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx17u/pull/219.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/219/head:pull/219

PR: https://git.openjdk.org/jfx17u/pull/219

From jvos at openjdk.org  Thu Nov 21 20:15:40 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:15:40 GMT
Subject: [jfx17u] Integrated: 8341920: Intermittent WebKit build failure on
 Windows generating PDB files in 619.1
In-Reply-To: <fVkF9_eOnmTYeaqGu3WPZr_VDE26mwFXWlMkHCTgFf0=.57b1cbf1-feba-477c-b556-160d000f184d@github.com>
References: <fVkF9_eOnmTYeaqGu3WPZr_VDE26mwFXWlMkHCTgFf0=.57b1cbf1-feba-477c-b556-160d000f184d@github.com>
Message-ID: <dXO0bjCdxuotFOOdM7CAXqZetvVKogCQ1kLkGNkUEzM=.527236f4-0a14-42a6-97bd-81c568b1839b@github.com>

On Thu, 21 Nov 2024 20:08:55 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0cafd801](https://github.com/openjdk/jfx/commit/0cafd8011b218162259b81872b1672a1a0649eef) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 14 Oct 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ee85e21e
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/ee85e21e948dafc9fab52d7184f460379f0c7e24
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8341920: Intermittent WebKit build failure on Windows generating PDB files in 619.1

Backport-of: 0cafd8011b218162259b81872b1672a1a0649eef

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

PR: https://git.openjdk.org/jfx17u/pull/219

From jvos at openjdk.org  Thu Nov 21 20:15:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:15:59 GMT
Subject: [jfx21u] Integrated: 8341920: Intermittent WebKit build failure on
 Windows generating PDB files in 619.1
Message-ID: <nXky4bnNLqYdKPcfc19YLFq-h5oddQF2KgQF3wY6eos=.bb5b9c27-eff1-4b57-b112-99c81975f508@github.com>

Hi all,

This pull request contains a backport of commit [0cafd801](https://github.com/openjdk/jfx/commit/0cafd8011b218162259b81872b1672a1a0649eef) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Hima Bindu Meda on 14 Oct 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

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

Commit messages:
 - Backport 0cafd8011b218162259b81872b1672a1a0649eef

Changes: https://git.openjdk.org/jfx21u/pull/84/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=84&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341920
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx21u/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/84/head:pull/84

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

From jvos at openjdk.org  Thu Nov 21 20:15:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:15:59 GMT
Subject: [jfx21u] Integrated: 8341920: Intermittent WebKit build failure on
 Windows generating PDB files in 619.1
In-Reply-To: <nXky4bnNLqYdKPcfc19YLFq-h5oddQF2KgQF3wY6eos=.bb5b9c27-eff1-4b57-b112-99c81975f508@github.com>
References: <nXky4bnNLqYdKPcfc19YLFq-h5oddQF2KgQF3wY6eos=.bb5b9c27-eff1-4b57-b112-99c81975f508@github.com>
Message-ID: <_tduiyZoANQnlpjj0b01kN_cdP5muy0zA4HLiRbFfS8=.0a970957-bdc7-47ac-a326-fb9ce23fa76f@github.com>

On Thu, 21 Nov 2024 20:08:49 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0cafd801](https://github.com/openjdk/jfx/commit/0cafd8011b218162259b81872b1672a1a0649eef) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 14 Oct 2024 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 8a77063a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/8a77063acadc41f30109ae4ab3c02988a73d9bd9
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8341920: Intermittent WebKit build failure on Windows generating PDB files in 619.1

Backport-of: 0cafd8011b218162259b81872b1672a1a0649eef

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

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

From angorya at openjdk.org  Thu Nov 21 20:17:29 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 20:17:29 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <B8DoZtQpVVy1ds97Cq_eQ07xpDX7ns0W7baGGTyrlg0=.f41eb5bb-9ec9-4f75-b222-59cdf1d9d471@github.com>

On Wed, 20 Nov 2024 23:45:53 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/FunctionTag.java line 51:
> 
>> 49: public final class FunctionTag {
>> 50:     /** Constructs the function tag. */
>> 51:     public FunctionTag() {
> 
> Should this be more than a simple "marker" Object with identity, but no state? There is no way to get the information from a particular function tag instance as to what it represents, nor is there a useful "toString()" method. There is also no way to get the set of available FunctionTag objects from the nested <Control>.Tag class. Perhaps we could be informed by the Enum class?
> 
> If there was value in doing this, maybe it could be a record?
> 
> 
>     public final record FunctionTag(String name) { }
> 
> 
> This would be mostly useful for tooling, since most applications aren't likely to need it.
> 
> It might be worth noting, even if you prefer not to make this change.

The main reason there is no name field in the FunctionTag is to simplify the life of custom components or internal skin developers.  There is just not enough value, in my opinion.

The argument about tooling is an interesting one.  At first glance, I think it is possible to retrieve both function tag name and the list of tags declared by the control using trivial reflection.

The other possibility is to forgo FunctionTag completely and just use naked Strings, losing some degree of type clarity.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852809036

From jvos at openjdk.org  Thu Nov 21 20:29:38 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:29:38 GMT
Subject: [jfx17u] RFR: 8343630: Pass AccessControlContext to/from WebKit as
 opaque object
Message-ID: <Kp6oFmnByia7qAwyuAGZpawEasxdpbSPnGot5lpYC2E=.90873feb-f50f-478a-ac4c-fa69f9247759@github.com>

Hi all,

This pull request contains a backport of commit fffa0fc4 from the openjdk/jfx repository.

The commit being backported was authored by Kevin Rushforth on 8 Nov 2024 and was reviewed by Andy Goryachev and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport fffa0fc4fd0f2ac332ae616066579c3b6b5a9861

Changes: https://git.openjdk.org/jfx17u/pull/220/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=220&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343630
  Stats: 8 lines in 3 files changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jfx17u/pull/220.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/220/head:pull/220

PR: https://git.openjdk.org/jfx17u/pull/220

From jvos at openjdk.org  Thu Nov 21 20:29:56 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:29:56 GMT
Subject: [jfx21u] RFR: 8343630: Pass AccessControlContext to/from WebKit as
 opaque object
Message-ID: <cYpL9wUKZ-yL-zJJPsKb7FgtDOVgxEVVOPRWdB00bfE=.572ae334-bce5-46f7-a583-d245996e98ef@github.com>

Hi all,

This pull request contains a backport of commit fffa0fc4 from the openjdk/jfx repository.

The commit being backported was authored by Kevin Rushforth on 8 Nov 2024 and was reviewed by Andy Goryachev and Jay Bhaskar.

Thanks!

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

Commit messages:
 - Backport fffa0fc4fd0f2ac332ae616066579c3b6b5a9861

Changes: https://git.openjdk.org/jfx21u/pull/85/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=85&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343630
  Stats: 8 lines in 3 files changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jfx21u/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/85/head:pull/85

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

From jvos at openjdk.org  Thu Nov 21 20:34:21 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:34:21 GMT
Subject: [jfx17u] Integrated: 8343630: Pass AccessControlContext to/from WebKit
 as opaque object
In-Reply-To: <Kp6oFmnByia7qAwyuAGZpawEasxdpbSPnGot5lpYC2E=.90873feb-f50f-478a-ac4c-fa69f9247759@github.com>
References: <Kp6oFmnByia7qAwyuAGZpawEasxdpbSPnGot5lpYC2E=.90873feb-f50f-478a-ac4c-fa69f9247759@github.com>
Message-ID: <X_w5x0W9sJ4A3stgY3uIyq0qnLS9re8SF-TmDiNP5lI=.0b4be16a-4ab8-4383-a4f7-ff3fa827dbc3@github.com>

On Thu, 21 Nov 2024 20:22:32 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit fffa0fc4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 8 Nov 2024 and was reviewed by Andy Goryachev and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: dd3c3615
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/dd3c3615967fff280a427ea4304fba9b6502b9be
Stats:     8 lines in 3 files changed: 2 ins; 1 del; 5 mod

8343630: Pass AccessControlContext to/from WebKit as opaque object

Backport-of: fffa0fc4fd0f2ac332ae616066579c3b6b5a9861

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

PR: https://git.openjdk.org/jfx17u/pull/220

From jvos at openjdk.org  Thu Nov 21 20:34:26 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 21 Nov 2024 20:34:26 GMT
Subject: [jfx21u] Integrated: 8343630: Pass AccessControlContext to/from WebKit
 as opaque object
In-Reply-To: <cYpL9wUKZ-yL-zJJPsKb7FgtDOVgxEVVOPRWdB00bfE=.572ae334-bce5-46f7-a583-d245996e98ef@github.com>
References: <cYpL9wUKZ-yL-zJJPsKb7FgtDOVgxEVVOPRWdB00bfE=.572ae334-bce5-46f7-a583-d245996e98ef@github.com>
Message-ID: <qldfpfmnBTXfza-OMS6l_4d9cooOuYSR1BND-3azTqQ=.06868a4c-ce69-469a-9c42-f715c85b6044@github.com>

On Thu, 21 Nov 2024 20:24:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit fffa0fc4 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 8 Nov 2024 and was reviewed by Andy Goryachev and Jay Bhaskar.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 7dd31c9c
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/7dd31c9c88026ba9b6f8f9dc468adf853e607935
Stats:     8 lines in 3 files changed: 2 ins; 1 del; 5 mod

8343630: Pass AccessControlContext to/from WebKit as opaque object

Backport-of: fffa0fc4fd0f2ac332ae616066579c3b6b5a9861

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

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

From angorya at openjdk.org  Thu Nov 21 20:38:32 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 20:38:32 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <ETn3NQnJ4kE_vTU1OR7svb1ohe40YLO9bX9zP45Hs-g=.2fc8d2e4-4cfc-41fc-8fc4-b786d7f9beaf@github.com>

On Wed, 20 Nov 2024 23:53:51 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 123:
> 
>> 121:      * and the {@code alt} key modifier ({@code option} on macOS).
>> 122:      * <p>
>> 123:      * This method is equivalent to {@link #option(KeyCode)} on macOS.
> 
> Then do we need both?

This and similar methods are added for convenience.  Every time I code a cross-platform application, I have to think - what is `option` key mapped to?  what is `meta`?  I don't want to think, or refer to a table (line 49).

So what I did was to add mac-specific methods that refer to mac-specific keys.  I think it makes my life easier, and hopefully I am not alone.  If enough negative feedback comes from the app developers, I am ok with removing these.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852851662

From angorya at openjdk.org  Thu Nov 21 20:43:31 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 20:43:31 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <WoBsPyRYnviCyZjvgogTyVqLy0VaVoa5m-qtns2Bub0=.a0161812-e96d-4682-b1da-7c29e728dd3f@github.com>

On Thu, 21 Nov 2024 00:00:27 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 269:
> 
>> 267:     /**
>> 268:      * Determines whether {@code alt} key is down in this key binding.
>> 269:      * @return true if {@code alt} key is down in this key binding
> 
> Does this return true if the `option` key is down on macOS?

I thought I got rid of it, it is unnecessary.  is[Modifier] methods will be removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852859271

From angorya at openjdk.org  Thu Nov 21 21:02:30 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 21:02:30 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <zTkmBh_3iTnLV7li6NLGpslHIxTZ_7MAAaUwQ8tbY_Y=.f425bf0d-8d49-4356-ad42-cedc44be87c9@github.com>

On Thu, 21 Nov 2024 00:02:17 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 343:
> 
>> 341:     /**
>> 342:      * Creates a {@link Builder} with the specified KeyCode.
>> 343:      * @param character the character
> 
> Since the type is String what if it is more than one character?

Good point.  Added a link to `KeyEvent.getCharacter()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852893089

From angorya at openjdk.org  Thu Nov 21 22:11:28 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 22:11:28 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <lTff7yJfZcZJ7b_1CR_Rv8RT0A_LLnb2VY9uYjOkvUs=.2bb8afc7-ca16-4339-992c-2e3eb68e1eba@github.com>

On Thu, 21 Nov 2024 19:20:47 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/EventCriteria.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This interface enables wider control in specifying conditional matching logic when adding skin/behavior handlers.
> 
> Can this interface be hidden as well? It may not need to be in the public API now that SkinInputMap and BehaviorBase aren't.
> 
> If it still needs to be part of the public API, it will need a better description. One that answers the questions: What is the purpose of this interface? Who implements it? Who uses it?

yes, it can be hidden for now.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1852973308

From angorya at openjdk.org  Thu Nov 21 22:40:27 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 22:40:27 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <5wFwJAbYsKf17R7NrRaHScwHZFiXpXyBe-_cakZ0KBg=.30cf2e99-098e-4890-847b-e1491c96b07a@github.com>

On Thu, 21 Nov 2024 19:24:44 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 36:
> 
>> 34: 
>> 35: /**
>> 36:  * Key binding provides a way to map key event to a hash table key for easy matching.
> 
> What, exactly, is the purpose of this class as public API? The above makes it sound like an implementation detail.
> 
> Also, what does it provide that KeyMapping doesn't?

`KeyMapping` is a totally different beast designed for a different purpose.

`KeyBinding` is more like `KeyCombination`, except we cannot use KeyCombination because:

- it does not capture KEY_PRESSED/KEY_TYPED/KEY_RELEASED property
- it has a sole KeyCombination(String) constructor which requires parsing
- it's got a narrow and weird API, unusable for our purpose

Also, this hints at the fact that the documentation needs to be improved, thanks.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1853027690

From angorya at openjdk.org  Thu Nov 21 22:57:28 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 22:57:28 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47]
In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <dzzM4Grh-G8fXWd_kZkd8W_SIPpvenQUmqytkzGhvkI=.eaf9d36d-cd26-46f5-9ecb-1e2120f04869@github.com>
 <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com>
Message-ID: <VwhBYumQMLqfvfthpmoUDed3WrA9sTVkHEXjN4J5yew=.d2998ff3-e729-4a2d-a12e-aa7c0e7003a7@github.com>

On Wed, 20 Nov 2024 23:58:50 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 66 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - hide skin input map
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - save as
>>  - removed function handler
>>  - removed add handler last
>>  - use focus traversal api
>>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>>  - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7
>
> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 198:
> 
>> 196:      * @return the KeyBinding, or null
>> 197:      */
>> 198:     public static KeyBinding shiftOption(KeyCode code) {
> 
> Is there a `shiftAlt` that would make sense on other platforms? If so, maybe that could supersede this?

I haven't needed shift-alt, but I suppose it can be added for other platforms.  shift-option, on the other hand is used on mac (in the TextInputControl hierarchy, for example).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1853054950

From angorya at openjdk.org  Thu Nov 21 23:15:49 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 21 Nov 2024 23:15:49 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v48]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <0agdZusUzT50z9h5-LMMBqLDTvQk9x1dST3V_YR-M1w=.2918e66c-8970-41ed-b00d-6b087f42150c@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/e45be7b7..1cd54b15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=47
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=46-47

  Stats: 139 lines in 8 files changed: 10 ins; 91 del; 38 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

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

From abhinay_agarwal at live.com  Fri Nov 22 10:20:35 2024
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Fri, 22 Nov 2024 10:20:35 +0000
Subject: Focus behavior on cell based controls
Message-ID: <D18BF019-1387-4D8A-8D5B-6341C173B975@live.com>

Hi,

Controls like ListView, TreeView, etc. always have one of the cells with focused property set to true.

This causes the focusWithin property [1] (introduced in 19) on these controls to be set to true even when the actual focus is neither on them nor its children.

I wonder if there is a reason for setting the focused property on one the cells always to true?

- Abhinay

[1] https://openjfx.io/javadoc/23/javafx.graphics/javafx/scene/Node.html#focusWithinProperty

From michaelstrau2 at gmail.com  Fri Nov 22 10:49:36 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 22 Nov 2024 11:49:36 +0100
Subject: Focus behavior on cell based controls
In-Reply-To: <D18BF019-1387-4D8A-8D5B-6341C173B975@live.com>
References: <D18BF019-1387-4D8A-8D5B-6341C173B975@live.com>
Message-ID: <CAJEpuXSDxj-g6a0NMjjnwDPTofsq0rQbUskc2epJQCYdT9Hnog@mail.gmail.com>

This was an unfortunate decision. The reason for this seems to be that
cell-based controls use the `focused` property in a non-standard way,
to remember the focused cell even when the input focus was moved to a
different control. There's no reason to do that, and can be fixed by
introducing a cell-specific property for this purpose (maybe
"retainedFocus", "cellFocus", or something like that). Controls should
never tamper with focus properties, as these are managed by the Node
class. We should probably deprecate the `Node.setFocused` method that
currently allows derived classes to change the focused property.


On Fri, Nov 22, 2024 at 11:20?AM Abhinay Agarwal
<abhinay_agarwal at live.com> wrote:
>
> Hi,
>
> Controls like ListView, TreeView, etc. always have one of the cells with focused property set to true.
>
> This causes the focusWithin property [1] (introduced in 19) on these controls to be set to true even when the actual focus is neither on them nor its children.
>
> I wonder if there is a reason for setting the focused property on one the cells always to true?
>
> - Abhinay
>
> [1] https://openjfx.io/javadoc/23/javafx.graphics/javafx/scene/Node.html#focusWithinProperty

From abhinay_agarwal at live.com  Fri Nov 22 12:05:19 2024
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Fri, 22 Nov 2024 12:05:19 +0000
Subject: Focus behavior on cell based controls
In-Reply-To: <CAJEpuXSDxj-g6a0NMjjnwDPTofsq0rQbUskc2epJQCYdT9Hnog@mail.gmail.com>
References: <D18BF019-1387-4D8A-8D5B-6341C173B975@live.com>
 <CAJEpuXSDxj-g6a0NMjjnwDPTofsq0rQbUskc2epJQCYdT9Hnog@mail.gmail.com>
Message-ID: <B101F474-512D-4738-B602-72E937BF8141@live.com>

Hi Michael,

Thank you for the explanation. I was confused to see focused still set to true on cells,
which is more prominent now with the introduction of `focusWithin`.

Deprecating `Note.setFocused` would need a major update across controls,
whereas an update in Cell to use cell-specific focus property seems harmless.

- Abhinay

> On 22 Nov 2024, at 4:19?PM, Michael Strau? <michaelstrau2 at gmail.com> wrote:
>
> This was an unfortunate decision. The reason for this seems to be that
> cell-based controls use the `focused` property in a non-standard way,
> to remember the focused cell even when the input focus was moved to a
> different control. There's no reason to do that, and can be fixed by
> introducing a cell-specific property for this purpose (maybe
> "retainedFocus", "cellFocus", or something like that). Controls should
> never tamper with focus properties, as these are managed by the Node
> class. We should probably deprecate the `Node.setFocused` method that
> currently allows derived classes to change the focused property.
>
>
> On Fri, Nov 22, 2024 at 11:20?AM Abhinay Agarwal
> <abhinay_agarwal at live.com> wrote:
>>
>> Hi,
>>
>> Controls like ListView, TreeView, etc. always have one of the cells with focused property set to true.
>>
>> This causes the focusWithin property [1] (introduced in 19) on these controls to be set to true even when the actual focus is neither on them nor its children.
>>
>> I wonder if there is a reason for setting the focused property on one the cells always to true?
>>
>> - Abhinay
>>
>> [1] https://openjfx.io/javadoc/23/javafx.graphics/javafx/scene/Node.html#focusWithinProperty


From mark.reinhold at oracle.com  Fri Nov 22 14:36:11 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Fri, 22 Nov 2024 14:36:11 +0000
Subject: =?utf-8?B?UmU6IFJlc3VsdDogTmV3IE9wZW5KRlggUmV2aWV3ZXI6IE1pY2hhZWwgU3Ry?=
 =?utf-8?B?YXXDnw==?=
In-Reply-To: <2a0f7e0d-4e92-4d3a-abfb-704981bf4c43@oracle.com>
References: <2a0f7e0d-4e92-4d3a-abfb-704981bf4c43@oracle.com>
Message-ID: <20241122093506.196274251@eggemoggin.niobe.net>

2024/11/19 12:16:56 -0500, kevin.rushforth at oracle.com:
> Voting for Michael Strau? [1] to OpenJFX Reviewer [2] is now closed.
> 
> Yes: 8
> Veto: 0
> Abstain: 0
> 
> According to the Bylaws definition of Three-Vote Consensus, this is 
> sufficient to approve the nomination.

So recorded.

- Mark

From kevin.rushforth at oracle.com  Fri Nov 22 14:48:50 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 Nov 2024 06:48:50 -0800
Subject: Result: New OpenJFX Committer: Jayathirth D V
Message-ID: <ab3e28c1-5f58-4b46-bcca-78499b9355ef@oracle.com>

Voting for Jayathirth D V [1] to OpenJFX Committer [2] is now closed.

Yes: 9
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#jdv

[2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050724.html


From andy.goryachev at oracle.com  Fri Nov 22 15:24:24 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 22 Nov 2024 15:24:24 +0000
Subject: Result: New OpenJFX Committer: Jayathirth D V
In-Reply-To: <ab3e28c1-5f58-4b46-bcca-78499b9355ef@oracle.com>
References: <ab3e28c1-5f58-4b46-bcca-78499b9355ef@oracle.com>
Message-ID: <BYAPR10MB301349149FB94F5CF884C999E5232@BYAPR10MB3013.namprd10.prod.outlook.com>

Congratulations, Jayathirth D V!

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Friday, November 22, 2024 at 06:49
To: registrar <registrar at openjdk.org>, Jayathirth Rao Daarapuram Venkatesh Murthy <jayathirth.d.v at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Result: New OpenJFX Committer: Jayathirth D V
Voting for Jayathirth D V [1] to OpenJFX Committer [2] is now closed.

Yes: 9
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#jdv

[2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050724.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241122/618f911d/attachment.htm>

From crschnick at xpipe.io  Fri Nov 22 15:32:07 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 22 Nov 2024 16:32:07 +0100
Subject: Nodes are not rendered after window resize
In-Reply-To: <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
References: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
 <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>
 <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
Message-ID: <018b325d-9338-4e5a-9826-96efb753b439@xpipe.io>

So I tried to catch the issue with the property enabled, but it only 
occurred at times when it was not enabled. And when I enabled the 
property after that, the issue didn't show up again ...

It's still very rare, but I think I have narrowed it down to it only 
occuring when the main memory of the system is almost used up. Every 
time it happened, my RAM usage was at 95%+ at least.

Is it possible that some kind of native allocation of memory for 
framebuffers or other stuff just silently fails in some part of the 
native JavaFX Windows code?

On 25/08/2024 14:15, Christopher Schnick wrote:
> Hello Eduard,
>
> thanks I will try that parameter. But I can already rule out that this 
> was fixed by the pull request as I used the latest JavaFX 24 ea build, 
> which already includes this fix.
>
> On 25/08/2024 14:06, Eduard Sedov wrote:
>> Hello Christopher,
>>
>> You can try to pass the following parameter to jvm:
>>
>> -Dprism.dirtyregioncount=1
>>
>> If it helps, then it's probably the same bug that was fixed in this 
>> pull request:
>>
>> https://github.com/openjdk/jfx/pull/1451
>>
>> - eduard
>>
>>
>> Am 25. Aug. 2024, 13:43, um 13:43, Christopher Schnick 
>> <crschnick at xpipe.io> schrieb:
>>> Hello,
>>>
>>> so it seems like there is a rare bug in JavaFX (at least on Windows)
>>> where after a resize operation, some controls are rendered as white
>>> boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10.
>>>
>>> There were no exceptions thrown or methods called from a non-platform
>>> thread. I was not able to reproduce this consistently so far. I would
>>> argue it happens around every 50 runs of an application for me.
>>>
>>> There were a couple of posts with videos of the problem:
>>> -
>>> https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/ 
>>>
>>> -
>>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html 
>>>
>>>
>>> (I wrongly reported it as a toolbar bug, it seems to be a more general
>>> one)
>>>
>>> I can sometimes enter this state shown in the videos by resizing a
>>> stage
>> >from for example 1280x720, to fullscreen, back to 1280x720, and to
>>> fullscreen again. It seems like the renderer dimensions become broken
>>> in
>>> some cases and are no longer updated on consecutive scene resize
>>> operations, so they always stay on an old value. If in this case the
>>> scene fits into a stage with size 1280x720 and is resized to
>>> fullscreen,
>>> any nodes outside the old scene bounds are rendered as these white
>>> artifacts, presumably because the renderer thinks that they are not
>>> visible. It seems like the renderer thinks they are outside the
>>> scene/stage because it still has the old scene dimensions. I was not
>>> able to get the application out of this invalid state without
>>> restarting it.
>>>
>>> If anyone could advise me on what kind of properties I can pass to
>>> JavaFX or what kind of actions I can do to narrow this down, that would
>>>
>>> be great.
>>>
>>> Best regards, Christopher

From angorya at openjdk.org  Fri Nov 22 16:19:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 16:19:50 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v11]
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: <TMFnFWLrt7yuOa6EuVngLGXRZPREodK7D5zQ5A4wWB8=.92b91517-4b58-414d-aa30-f08883efff3a@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 24
>      */
>     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 24
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> ## Discussion Points
> 
> - it is unclear whether CaretInfo.getPartAt() should return a simple Rectangle2D or a more complex object similar to TextLineInfo, to be able to add more information, such as the nature of text, text direction, etc.
> 
> 
> ## 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/Rich...

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

 - segments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - coordinates
 - note
 - text layout test
 - text flow test
 - shorter array
 - line spacing
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - ... and 24 more: https://git.openjdk.org/jfx/compare/c212a835...944bd0d3

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/d31eb2b2..944bd0d3

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

  Stats: 47 lines in 7 files changed: 27 ins; 1 del; 19 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 kcr at openjdk.org  Fri Nov 22 16:36:02 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Nov 2024 16:36:02 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
Message-ID: <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>

> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
> 
> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
> 2. A utility class to produce warnings when first using an incubator module.
> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
> 
> See PR #1617 for a sample module that is built on top of this PR's source branch.
> 
> This is almost ready to review. I will take it out of Draft in the next day or so.

Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
 - Remove call to doPrivileged
 - 8309381: Support JavaFX incubator modules

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1616/files
  - new: https://git.openjdk.org/jfx/pull/1616/files/7f2632a2..1d262fb3

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

  Stats: 9693 lines in 252 files changed: 3845 ins; 3914 del; 1934 mod
  Patch: https://git.openjdk.org/jfx/pull/1616.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1616/head:pull/1616

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

From mhanl at openjdk.org  Fri Nov 22 16:37:37 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 16:37:37 GMT
Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in
 horizontal direction
Message-ID: <cYnfPs9oZZjoLfEtm--rTDA4tzRIbWXVj89M_JuNhqk=.eb4a3cbb-d83f-49d2-a88f-fa41fbbade4e@github.com>

This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy.

In order to do that, there are multiple things needed:
- the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there
  - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be)
  - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed)
- To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns
- As before, the `TableRow` adds or removes cells that are visible or not. 
Note that this is only done when a fixed cell size is set. 
The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later
- The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed:
  - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells
  Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself
  - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), as mentioned above
  
  The fix is to remove those cells from the viewport when not needed anymore.
  NOTE: The `VirtualFlow` does a lot of 'clean up everything and decide which cells are visible', so I chose a performant fix (instead of removing all cells and readding them again)
  NOTE2: This makes the logic to make cells invisible and visible again obsolete. This was there so those unused cells laying around in the `VirtualFlow` does not receive any Mouse or KeyEvents. This can be cleaned up in a follow up PR

Considerations:
-
- I decided to not do more logic like batching all cells that should be removed (`removeAll`), as the scenario that mostly happens is:
  - You start scrolling to the right, we add and remove cells one by one
  - Therefore, we mostly do not remove or add multiple cells at once anyway
- Other bigger refactoring for performance can be done in a follow up (if we find things, I do not want to blow up this PR)

Testing:
-
- I added many tests to cover all possible scenarios, including:
  - Reordering a column
  - Decrease/Increase column width
  - Adding and removing columns
  - Scrolling around and checking, that no empty cells are around ([JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326)
- I did lots of testing on my own and also on JavaFX applications. I found no regression
- Some tests need to be adjusted since the fix also improves `TreeTableRow` code, which before added `LabeledText` sometimes (from `LabeledSkinBase`), although it was not needed, leading to code that need to count that particular node in, in some tests
- Remove ` VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE` which was hacky and replaced it with the normal `StageLoader` mechanism (as we use pretty much everywhere else)

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

Commit messages:
 - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction

Changes: https://git.openjdk.org/jfx/pull/1644/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8185887
  Stats: 1340 lines in 14 files changed: 1170 ins; 135 del; 35 mod
  Patch: https://git.openjdk.org/jfx/pull/1644.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644

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

From mhanl at openjdk.org  Fri Nov 22 16:45:36 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 16:45:36 GMT
Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells
 in horizontal direction [v2]
In-Reply-To: <cYnfPs9oZZjoLfEtm--rTDA4tzRIbWXVj89M_JuNhqk=.eb4a3cbb-d83f-49d2-a88f-fa41fbbade4e@github.com>
References: <cYnfPs9oZZjoLfEtm--rTDA4tzRIbWXVj89M_JuNhqk=.eb4a3cbb-d83f-49d2-a88f-fa41fbbade4e@github.com>
Message-ID: <HwmlxyO615MtoLpaps3uPaoWQVlpmspEZA1PpYHImXg=.7afda9bd-c343-42ff-8d36-286b9d4ee0a5@github.com>

> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy.
> 
> In order to do that, there are multiple things needed:
> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there
>   - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be)
>   - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed)
> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns
> - As before, the `TableRow` adds or removes cells that are visible or not. 
> Note that this is only done when a fixed cell size is set. 
> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later
> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed:
>   - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells
>   Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself
>   - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org...

Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1644/files
  - new: https://git.openjdk.org/jfx/pull/1644/files/62f46c62..e8115729

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

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

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

From crschnick at xpipe.io  Fri Nov 22 16:50:59 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 22 Nov 2024 17:50:59 +0100
Subject: Nodes are not rendered after window resize
In-Reply-To: <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
References: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
 <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>
 <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
Message-ID: <36244953-4dd7-4593-8aac-c633091e8ae7@xpipe.io>

So I tried to catch the issue with the property enabled, but it only 
occurred at times when it was not enabled. And when I enabled the 
property after that, the issue didn't show up again ... It's still very 
rare, but I think I have narrowed it down to it only occuring when the 
main memory of the system is almost used up. Every time it happened, my 
RAM usage was at 95%+ at least.

Is it possible that some kind of native allocation of memory for 
framebuffers or other stuff just silently fails in some part of the 
JavaFX Windows code?


Unrelated to that, it seems like another email of mine got blocked again 
by the mailing list size limit. 4Mb is still quite limiting for multiple 
screenshots in my opinion.


On 25/08/2024 14:15, Christopher Schnick wrote:
> Hello Eduard,
>
> thanks I will try that parameter. But I can already rule out that this 
> was fixed by the pull request as I used the latest JavaFX 24 ea build, 
> which already includes this fix.
>
> On 25/08/2024 14:06, Eduard Sedov wrote:
>> Hello Christopher,
>>
>> You can try to pass the following parameter to jvm:
>>
>> -Dprism.dirtyregioncount=1
>>
>> If it helps, then it's probably the same bug that was fixed in this 
>> pull request:
>>
>> https://github.com/openjdk/jfx/pull/1451
>>
>> - eduard
>>
>>
>> Am 25. Aug. 2024, 13:43, um 13:43, Christopher Schnick 
>> <crschnick at xpipe.io> schrieb:
>>> Hello,
>>>
>>> so it seems like there is a rare bug in JavaFX (at least on Windows)
>>> where after a resize operation, some controls are rendered as white
>>> boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10.
>>>
>>> There were no exceptions thrown or methods called from a non-platform
>>> thread. I was not able to reproduce this consistently so far. I would
>>> argue it happens around every 50 runs of an application for me.
>>>
>>> There were a couple of posts with videos of the problem:
>>> -
>>> https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/ 
>>>
>>> -
>>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html 
>>>
>>>
>>> (I wrongly reported it as a toolbar bug, it seems to be a more general
>>> one)
>>>
>>> I can sometimes enter this state shown in the videos by resizing a
>>> stage
>> >from for example 1280x720, to fullscreen, back to 1280x720, and to
>>> fullscreen again. It seems like the renderer dimensions become broken
>>> in
>>> some cases and are no longer updated on consecutive scene resize
>>> operations, so they always stay on an old value. If in this case the
>>> scene fits into a stage with size 1280x720 and is resized to
>>> fullscreen,
>>> any nodes outside the old scene bounds are rendered as these white
>>> artifacts, presumably because the renderer thinks that they are not
>>> visible. It seems like the renderer thinks they are outside the
>>> scene/stage because it still has the old scene dimensions. I was not
>>> able to get the application out of this invalid state without
>>> restarting it.
>>>
>>> If anyone could advise me on what kind of properties I can pass to
>>> JavaFX or what kind of actions I can do to narrow this down, that would
>>>
>>> be great.
>>>
>>> Best regards, Christopher

From mhanl at openjdk.org  Fri Nov 22 17:10:32 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 17:10:32 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
Message-ID: <ef69FixrwLP1Sla6mqpqg-TpXdl_aPIlbX2R5t_scDo=.bd358946-67c5-4448-b073-d50efed738b3@github.com>

> There are multiple issues in the `TableMenu` logic that result in a memory leak.
> 
> The following problems are now fixed with this PR:
> - The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
>    - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
> - The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
>   - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  8341687: Add more tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1640/files
  - new: https://git.openjdk.org/jfx/pull/1640/files/c6c62f94..8968d4ac

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

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

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

From mhanl at openjdk.org  Fri Nov 22 17:10:32 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 17:10:32 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <wiBVo0ULCGioa2SLzX0Alg2VnDcaHXkWFJBNfdO0pOY=.7e7144fa-29ce-4e06-8b3c-2880df4c2a9e@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <xXea14Urok1S95wQroZ4yM5Is0BO_gCBooJTX_9u3o0=.338baff8-431a-4c6d-8290-1fc998e21185@github.com>
 <wiBVo0ULCGioa2SLzX0Alg2VnDcaHXkWFJBNfdO0pOY=.7e7144fa-29ce-4e06-8b3c-2880df4c2a9e@github.com>
Message-ID: <6NUr-cLCphWczZHefUx7Zr006t7SeHxur2MYAFiwPio=.2960c582-18d5-4b64-9ea9-582608b48b6c@github.com>

On Mon, 18 Nov 2024 20:21:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I tried, but it isn't that easy - since the memory is not leaked because we keep some references we should not keep - rather we are adding listener again and again and again. So we can not assert things to be collectable, as they should not be, still they increase the memory footprint instead.
>> 
>> So I did not manage to make a test with `JMemoryBuddy`, but can prove the point with the amount of listener instead.
>> 
>> I wrote a test that checked, that the memory is similar high as before, that worked as well but I was afraid that is might be flaky, which I want to avoid.
>
> I think this is an acceptable explanation as it tests the root cause of the leak.
> 
> Do you think changing the skin would allow us to create a test for the memory leak specifically.  Maybe some variation of `SkinMemoryLeakTest` ?

Found a way to test it with `JMemoryBuddy`. Kept the listener tests as well, since they also prove the point.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854312461

From angorya at openjdk.org  Fri Nov 22 17:47:20 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 17:47:20 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <ef69FixrwLP1Sla6mqpqg-TpXdl_aPIlbX2R5t_scDo=.bd358946-67c5-4448-b073-d50efed738b3@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <ef69FixrwLP1Sla6mqpqg-TpXdl_aPIlbX2R5t_scDo=.bd358946-67c5-4448-b073-d50efed738b3@github.com>
Message-ID: <KMhgN9yRzmXafWfka37mLppL8OCvv9ABpApslf-ODAc=.dafa16d2-3f46-4b92-823a-a59bddb32497@github.com>

On Fri, 22 Nov 2024 17:10:32 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> There are multiple issues in the `TableMenu` logic that result in a memory leak.
>> 
>> The following problems are now fixed with this PR:
>> - The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
>>    - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
>> - The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
>>   - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341687: Add more tests

thank you for adding the memory leak test!
the tests fail in the master, and pass with the fixes in this PR.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1640#pullrequestreview-2455225720

From crschnick at xpipe.io  Fri Nov 22 17:56:55 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 22 Nov 2024 18:56:55 +0100
Subject: Nodes are not rendered after window resize
In-Reply-To: <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
References: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
 <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>
 <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>
Message-ID: <9c9f09c1-c297-45df-9adc-8b6ad7f453da@xpipe.io>

So I tried to catch the issue with the property enabled, but it only 
occurred at times when it was not enabled. And when I enabled the 
property after that, the issue didn't show up again ... It's still very 
rare, but I think I have narrowed it down to it only occuring when the 
main memory of the system is almost used up. Every time it happened, my 
RAM usage was at 95%+ at least.

Is it possible that some kind of native allocation of memory for 
framebuffers or other stuff just silently fails in some part of the 
JavaFX Windows code?


Unrelated to that, it seems like another email of mine got blocked again 
by the mailing list size limit. 4Mb is still quite limiting for multiple 
screenshots in my opinion.


On 25/08/2024 14:15, Christopher Schnick wrote:
> Hello Eduard,
>
> thanks I will try that parameter. But I can already rule out that this 
> was fixed by the pull request as I used the latest JavaFX 24 ea build, 
> which already includes this fix.
>
> On 25/08/2024 14:06, Eduard Sedov wrote:
>> Hello Christopher,
>>
>> You can try to pass the following parameter to jvm:
>>
>> -Dprism.dirtyregioncount=1
>>
>> If it helps, then it's probably the same bug that was fixed in this 
>> pull request:
>>
>> https://github.com/openjdk/jfx/pull/1451
>>
>> - eduard
>>
>>
>> Am 25. Aug. 2024, 13:43, um 13:43, Christopher Schnick 
>> <crschnick at xpipe.io> schrieb:
>>> Hello,
>>>
>>> so it seems like there is a rare bug in JavaFX (at least on Windows)
>>> where after a resize operation, some controls are rendered as white
>>> boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10.
>>>
>>> There were no exceptions thrown or methods called from a non-platform
>>> thread. I was not able to reproduce this consistently so far. I would
>>> argue it happens around every 50 runs of an application for me.
>>>
>>> There were a couple of posts with videos of the problem:
>>> -
>>> https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/ 
>>>
>>> -
>>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html 
>>>
>>>
>>> (I wrongly reported it as a toolbar bug, it seems to be a more general
>>> one)
>>>
>>> I can sometimes enter this state shown in the videos by resizing a
>>> stage
>> >from for example 1280x720, to fullscreen, back to 1280x720, and to
>>> fullscreen again. It seems like the renderer dimensions become broken
>>> in
>>> some cases and are no longer updated on consecutive scene resize
>>> operations, so they always stay on an old value. If in this case the
>>> scene fits into a stage with size 1280x720 and is resized to
>>> fullscreen,
>>> any nodes outside the old scene bounds are rendered as these white
>>> artifacts, presumably because the renderer thinks that they are not
>>> visible. It seems like the renderer thinks they are outside the
>>> scene/stage because it still has the old scene dimensions. I was not
>>> able to get the application out of this invalid state without
>>> restarting it.
>>>
>>> If anyone could advise me on what kind of properties I can pass to
>>> JavaFX or what kind of actions I can do to narrow this down, that would
>>>
>>> be great.
>>>
>>> Best regards, Christopher

From angorya at openjdk.org  Fri Nov 22 18:00:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 18:00:50 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v49]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <Q8lDiGcteHnNU1yKejIg2RbZJjhCXlzarlg5DXTnh6Y=.a9b43a83-6e55-4d9b-993e-6e0ccf7be759@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  since 24

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/1cd54b15..e453f61c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=48
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=47-48

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

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

From angorya at openjdk.org  Fri Nov 22 18:07:14 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 18:07:14 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v50]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <tmO-4alIYwGF8krmmGN3mhCv8DrIUswJCRYjIXj1isE=.fba963b8-2c6f-48f9-99e8-8ec11f28f98c@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/e453f61c..b6013270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=49
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=48-49

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

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

From mhanl at openjdk.org  Fri Nov 22 18:08:21 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 18:08:21 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
Message-ID: <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>

On Mon, 18 Nov 2024 16:13:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8341687: Add more tests
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 641:
> 
>> 639: 
>> 640:             final CheckMenuItem _item = item;
>> 641:             // fake bidrectional binding (a real one was used here but resulted in JBS-8136468)
> 
> that's JDK-8136468

maybe we we should do a small cleanup ticket where we replace all `JBS-` and `RT-` references with the `JDK-` one? A quick check led to around 120 occurrences.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854429161

From angorya at openjdk.org  Fri Nov 22 18:11:21 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 18:11:21 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
Message-ID: <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>

On Fri, 22 Nov 2024 18:05:36 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 641:
>> 
>>> 639: 
>>> 640:             final CheckMenuItem _item = item;
>>> 641:             // fake bidrectional binding (a real one was used here but resulted in JBS-8136468)
>> 
>> that's JDK-8136468
>
> maybe we we should do a small cleanup ticket where we replace all `JBS-` and `RT-` references with the `JDK-` one? A quick check led to around 120 occurrences.

and maybe fix the RT- references as well, though it might be a bit harder because a  lookup is required.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854442807

From andy.goryachev at oracle.com  Fri Nov 22 18:50:15 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 22 Nov 2024 18:50:15 +0000
Subject: Focus delegation API
In-Reply-To: <CAJEpuXRrQwnS2cVYAPsq5migrWhRVBe97=Z0cPnR3CyGv1XLQQ@mail.gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB3013A4B3062D686CDE6C147EE55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXRrQwnS2cVYAPsq5migrWhRVBe97=Z0cPnR3CyGv1XLQQ@mail.gmail.com>
Message-ID: <BYAPR10MB3013CE02A6A4862D59A34052E5232@BYAPR10MB3013.namprd10.prod.outlook.com>

> I don't see how these problems are at all related.

I failed to explain it clearly then.  I'll try to write up a more detailed explanation after Thanksgiving.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Wednesday, November 20, 2024 at 14:42
To:
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Focus delegation API
I don't see how these problems are at all related.

My proposal solves the focus delegation problem that is inherent with
composite controls, which is not even addressed by the InputMap
proposal.

It also solves an artifact of the event system, namely that key events
are delivered to the focused node, which cannot simultaneously be the
Spinner and its TextField. The ugly hack to make this work is to
duplicate the event entirely, so that if you'd observe Spinner and
listen for key events, you will see duplicated key presses. This is
also not solved in any meaningful way by InputMap.



On Wed, Nov 13, 2024 at 8:33?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> I feel this is going in a wrong direction: the root cause of the issues we are observing, in my opinion, is that the top-level Control is fighting for control with the inner control, and the inner control's behaves as if it is a top-level control.
>
> What should happen instead is to provide a way for the top-level Control to disable those aspects of the inner control behavior (event handlers, key bindings) that are not needed anymore, and replace them with the new logic.
> Continuing the Spinner example, it is ok for the TextField (Spinner.editor) to receive events, but the handling of certain key combinations should be disabled and instead bubbled up to the Spinner behavior.
>
> I propose to use the InputMap https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md for this purpose.
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241122/56d7f01b/attachment-0001.htm>

From kcr at openjdk.org  Fri Nov 22 19:37:19 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Nov 2024 19:37:19 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
Message-ID: <zGS95bV1x9CnyGDvyQ0tpfh0OcaE4vF63FRw01NxVcY=.355d8d31-a2ce-471a-9040-ae02e120b212@github.com>

On Fri, 22 Nov 2024 16:36:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
>> 
>> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
>> 2. A utility class to produce warnings when first using an incubator module.
>> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
>> 
>> See PR #1617 for a sample module that is built on top of this PR's source branch.
>> 
>> This is almost ready to review. I will take it out of Draft in the next day or so.
>
> Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
>  - Remove call to doPrivileged
>  - 8309381: Support JavaFX incubator modules

I made the changes to split out the build logic from `build.gradle` so that adding a new incubator module will not require touching the main `build.gradle` file. I pushed this to a new [8309381-incubator.v2](https://github.com/kevinrushforth/jfx/tree/8309381-incubator.v2) branch to evaluate whether to update this PR with that approach.

Click here to see [the diff between this PR branch and v2](https://github.com/kevinrushforth/jfx/compare/8309381-incubator...8309381-incubator.v2).

See [README-incubator.md](https://github.com/kevinrushforth/jfx/blob/8309381-incubator.v2/README-incubator.md) for instructions on creating a new incubator module.

I also updated the sample incubator module, `jfx.incubator.myfeature` in my [jfx.incubator.v2](https://github.com/kevinrushforth/jfx/tree/jfx.incubator.v2) branch.

Click here to see [the jfx.incubator.v2 diffs](https://github.com/kevinrushforth/jfx/compare/jfx.incubator...jfx.incubator.v2).

@andy-goryachev-oracle Can you take a look?

I do think it makes a better separation to get the build logic out of build.gradle, but I wonder whether we want to wait and do this as part of the larger build.gradle cleanup.

@nlisker @johanvos What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2494645757

From angorya at openjdk.org  Fri Nov 22 19:54:20 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 19:54:20 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod [v3]
In-Reply-To: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com>
References: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
 <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com>
Message-ID: <lvtVxuOHIZGx12PQKswc7DzqbL5ENGdMZEfR_g39L8A=.6fa77f59-4572-4420-8144-40dc58f7019e@github.com>

On Tue, 12 Nov 2024 15:08:11 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Input methods don?t work for text controls inside Popups. This PR fixes that.
>> 
>> Some background:
>> 
>> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows.
>> 
>> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom.
>> 
>> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene.
>> 
>> There are several reasons why Input Methods aren?t currently working for Popups.
>> 
>> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents.
>> 
>> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events.
>> 
>> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents.
>> 
>> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack.
>> 
>> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha...
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak to satisfy system test.

I'll take a look at it after Thanksgiving.

Somewhat related questions (sorry if totally unrelated):

Q1. shouldn't the input method be tied to the `Scene.focusOwner` property somehow?
Q2. given the fact that there could be only one active IM in the application, shouldn't there be a static `currentInputFocusOwner` property somewhere?

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

PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2494682931

From angorya at openjdk.org  Fri Nov 22 20:00:22 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 20:00:22 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <hTfvB2u68IOlFVPlpxJYceWIKHiQtUMfQB-XpfKzhR8=.0d645994-9076-4090-8ff9-bf40dccb4c3e@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <hTfvB2u68IOlFVPlpxJYceWIKHiQtUMfQB-XpfKzhR8=.0d645994-9076-4090-8ff9-bf40dccb4c3e@github.com>
Message-ID: <LiayXbb2G538bFhzGDJ_z704jvsqmja1Vw531_lMWi8=.cac27872-bd2b-4edc-b230-d3ec1881d081@github.com>

On Tue, 5 Nov 2024 22:38:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
>>  - Remove call to doPrivileged
>>  - 8309381: Support JavaFX incubator modules
>
> looks consistent with the original changes, but easier to understand.
> 
> had a few minor suggestions, will re-approve if you decide to fix it (WRAIYDTFI).

> @andy-goryachev-oracle Can you take a look?

could you create a draft PR for v2, so we can leave comments?

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

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2494693909

From kcr at openjdk.org  Fri Nov 22 20:35:21 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Nov 2024 20:35:21 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <LiayXbb2G538bFhzGDJ_z704jvsqmja1Vw531_lMWi8=.cac27872-bd2b-4edc-b230-d3ec1881d081@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <hTfvB2u68IOlFVPlpxJYceWIKHiQtUMfQB-XpfKzhR8=.0d645994-9076-4090-8ff9-bf40dccb4c3e@github.com>
 <LiayXbb2G538bFhzGDJ_z704jvsqmja1Vw531_lMWi8=.cac27872-bd2b-4edc-b230-d3ec1881d081@github.com>
Message-ID: <koiLfIYxvwP-6hpYXtH3y5aW8gbIPow7whxG6J_F9Z0=.47f08acf-44d9-40f3-bec1-ba836306869d@github.com>

On Fri, 22 Nov 2024 19:57:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> could you create a draft PR for v2, so we can leave comments?

Done. I created Draft PR #1646

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

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2494748813

From mhanl at openjdk.org  Fri Nov 22 20:35:45 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 20:35:45 GMT
Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by
 live lookup
Message-ID: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>

This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners.

While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set.

It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745).
Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect.

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

Commit messages:
 - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup

Changes: https://git.openjdk.org/jfx/pull/1645/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277000
  Stats: 140 lines in 5 files changed: 78 ins; 44 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1645.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1645/head:pull/1645

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

From mhanl at openjdk.org  Fri Nov 22 20:35:45 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 20:35:45 GMT
Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to
 fixedCellSize by live lookup
In-Reply-To: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
References: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
Message-ID: <esNkiRoNlWiQT1lLJGiCuS2Eo6MqgJOO5KJJFZpXji4=.d09d3a36-7f85-4c49-b7b2-4b4b49862099@github.com>

On Fri, 22 Nov 2024 20:31:08 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners.
> 
> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set.
> 
> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745).
> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 100:

> 98:         ListenerHelper lh = ListenerHelper.get(this);
> 99: 
> 100:         lh.addChangeListener(control.indexProperty(), (ev) -> {

Since https://github.com/openjdk/jfx/pull/1635 got merged, this is not needed as `TableRowSkinBase` does that already:
`registerChangeListener(control.indexProperty(), e -> requestCellUpdate());`. So this is basically a noop.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1854618103

From kcr at openjdk.org  Fri Nov 22 20:58:19 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Nov 2024 20:58:19 GMT
Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells
 in horizontal direction [v2]
In-Reply-To: <HwmlxyO615MtoLpaps3uPaoWQVlpmspEZA1PpYHImXg=.7afda9bd-c343-42ff-8d36-286b9d4ee0a5@github.com>
References: <cYnfPs9oZZjoLfEtm--rTDA4tzRIbWXVj89M_JuNhqk=.eb4a3cbb-d83f-49d2-a88f-fa41fbbade4e@github.com>
 <HwmlxyO615MtoLpaps3uPaoWQVlpmspEZA1PpYHImXg=.7afda9bd-c343-42ff-8d36-286b9d4ee0a5@github.com>
Message-ID: <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com>

On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy.
>> 
>> In order to do that, there are multiple things needed:
>> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there
>>   - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be)
>>   - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed)
>> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns
>> - As before, the `TableRow` adds or removes cells that are visible or not. 
>> Note that this is only done when a fixed cell size is set. 
>> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later
>> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed:
>>   - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells
>>   Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself
>>   - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763...
>
> Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction

We will need to check that this doesn't impact accessibility, since there are some "interesting" cases where cells are requested and a layout pass is done even when they aren't visible.

@arapte As I recall, you were looking into VirtualFlow in connection with an a11y at one point. Can you test this?

@johanvos You may want to take a look since this touches VirtualFlow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2494784599
PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2494785636

From mhanl at openjdk.org  Fri Nov 22 21:07:21 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 21:07:21 GMT
Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells
 in horizontal direction [v2]
In-Reply-To: <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com>
References: <cYnfPs9oZZjoLfEtm--rTDA4tzRIbWXVj89M_JuNhqk=.eb4a3cbb-d83f-49d2-a88f-fa41fbbade4e@github.com>
 <HwmlxyO615MtoLpaps3uPaoWQVlpmspEZA1PpYHImXg=.7afda9bd-c343-42ff-8d36-286b9d4ee0a5@github.com>
 <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com>
Message-ID: <62PHjSk1eOi3VgqtDxku28P2edyqJtwLHj0auRzOGp0=.4f193ae5-fc9c-4e6f-abaf-2664a45cd7e8@github.com>

On Fri, 22 Nov 2024 20:55:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We will need to check that this doesn't impact accessibility, since there are some "interesting" cases where cells are requested and a layout pass is done even when they aren't visible.

Good point! Checking `getPrivateCell`, I wonder why we do not use the `accumCell` here, we rather add a cell into the sheet (although it is not visible) and return it. With the changes made in this PR, this cell will be cleaned up later. So worth checking!

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

PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2494798911

From mhanl at openjdk.org  Fri Nov 22 21:16:18 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 22 Nov 2024 21:16:18 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
 <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>
Message-ID: <WdCmVGvNWjG0AeerwOYwHKmQXv50-3a8oe77XddP4js=.1e30fd9c-de26-4858-8550-f2af8ee2e2b8@github.com>

On Fri, 22 Nov 2024 18:09:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> maybe we we should do a small cleanup ticket where we replace all `JBS-` and `RT-` references with the `JDK-` one? A quick check led to around 120 occurrences.
>
> and maybe fix the RT- references as well, though it might be a bit harder because a  lookup is required.

That is correct. I still think it's worth it, especially since not everyone knows the 'trick' of pasting the `RT-` entry into the bug tracker to get the corresponding `JDK-` entry (in fact, I only learned that this year ?)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854669332

From kevin.rushforth at oracle.com  Fri Nov 22 21:19:03 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 22 Nov 2024 13:19:03 -0800
Subject: JavaFX 23.0.2 will be closed for fixes on December 2nd
Message-ID: <98fd21e0-3a2b-4753-8103-1c2920b4b51a@oracle.com>

All,

If you have backports that you want to get into jfx23u for JavaFX 
23.0.2, please do so by Monday, December 2nd. Note that approval from 
one of the project leads is needed as outlined in this message [1].

Thanks.

-- Kevin

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-July/048051.html


From angorya at openjdk.org  Fri Nov 22 21:24:19 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 21:24:19 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <WdCmVGvNWjG0AeerwOYwHKmQXv50-3a8oe77XddP4js=.1e30fd9c-de26-4858-8550-f2af8ee2e2b8@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
 <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>
 <WdCmVGvNWjG0AeerwOYwHKmQXv50-3a8oe77XddP4js=.1e30fd9c-de26-4858-8550-f2af8ee2e2b8@github.com>
Message-ID: <ijtXBYo4z1RQ0V0MKx5RoRLaPOmOEFqMUQMbeiHMOXw=.f5567375-f63e-494b-8aee-ccbfecec75de@github.com>

On Fri, 22 Nov 2024 21:13:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> and maybe fix the RT- references as well, though it might be a bit harder because a  lookup is required.
>
> That is correct. I still think it's worth it, especially since not everyone knows the 'trick' of pasting the `RT-` entry into the bug tracker to get the corresponding `JDK-` entry (in fact, I only learned that this year ?)

I'd review that!  The only question is how to do RT- efficiently, so it can be easily reviewed (without going through manually copying and pasting every id)...

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854697257

From kcr at openjdk.org  Fri Nov 22 21:36:18 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Nov 2024 21:36:18 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <ijtXBYo4z1RQ0V0MKx5RoRLaPOmOEFqMUQMbeiHMOXw=.f5567375-f63e-494b-8aee-ccbfecec75de@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
 <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>
 <WdCmVGvNWjG0AeerwOYwHKmQXv50-3a8oe77XddP4js=.1e30fd9c-de26-4858-8550-f2af8ee2e2b8@github.com>
 <ijtXBYo4z1RQ0V0MKx5RoRLaPOmOEFqMUQMbeiHMOXw=.f5567375-f63e-494b-8aee-ccbfecec75de@github.com>
Message-ID: <2An5VleHG6haZsVCDo_V_oF5gzWhmRokNT1iFQ61CLw=.ac838c45-a76d-4a15-8f58-1d018330047b@github.com>

On Fri, 22 Nov 2024 21:21:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> That is correct. I still think it's worth it, especially since not everyone knows the 'trick' of pasting the `RT-` entry into the bug tracker to get the corresponding `JDK-` entry (in fact, I only learned that this year ?)
>
> I'd review that!  The only question is how to do RT- efficiently, so it can be easily reviewed (without going through manually copying and pasting every id)...

It would be pretty easy to do it with a JIRA REST query: Given an input list of `RT-nnnn` bug IDs, produce the corresponding output list of `JDK-mmmmmmm` bug IDs. I'll volunteer to do this part of it.

Someone could then easily turn that into a script using `sed` to do the replacement.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1854732914

From angorya at openjdk.org  Fri Nov 22 21:48:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 21:48:23 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v11]
In-Reply-To: <TMFnFWLrt7yuOa6EuVngLGXRZPREodK7D5zQ5A4wWB8=.92b91517-4b58-414d-aa30-f08883efff3a@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <TMFnFWLrt7yuOa6EuVngLGXRZPREodK7D5zQ5A4wWB8=.92b91517-4b58-414d-aa30-f08883efff3a@github.com>
Message-ID: <O7_OkcEPrU-J4zli1-2jFLYcRImMtkMBtcY5wg40nUY=.594cf753-a2be-4c45-8e90-4d092d2c8944@github.com>

On Fri, 22 Nov 2024 16:19:50 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 24
>>      */
>>     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 24
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> ## Discussion Points
>> 
>> - it is unclear whether CaretInfo.getPartAt() should return a simple Rectangle2D or a more complex object similar to TextLineInfo, to be able to add more information, such as the nature of text, text direction, etc.
>> 
>> 
>> ## 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...
>
> 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 34 additional commits since the last revision:
> 
>  - segments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - coordinates
>  - note
>  - text layout test
>  - text flow test
>  - shorter array
>  - line spacing
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 24 more: https://git.openjdk.org/jfx/compare/8302d1b2...944bd0d3

@prrace please take a look

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2494915484

From mfox at openjdk.org  Fri Nov 22 22:16:20 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 22 Nov 2024 22:16:20 GMT
Subject: RFR: 8288893: Popup and its subclasses cannot input text from
 InputMethod [v3]
In-Reply-To: <lvtVxuOHIZGx12PQKswc7DzqbL5ENGdMZEfR_g39L8A=.6fa77f59-4572-4420-8144-40dc58f7019e@github.com>
References: <cRfkz1NL0M_9hFmgo8kDQYzKCgMzUDuUtCk4f83zM9o=.6278f22a-098a-4311-acd1-e300808e97a7@github.com>
 <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com>
 <lvtVxuOHIZGx12PQKswc7DzqbL5ENGdMZEfR_g39L8A=.6fa77f59-4572-4420-8144-40dc58f7019e@github.com>
Message-ID: <t0NrYdxq6OVWj-7-ZxAEIfio6VkY1d9qFsuZxkNIcl0=.5b3f0a32-fd17-42dd-aeb5-991d61a5fdd9@github.com>

On Fri, 22 Nov 2024 19:51:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak to satisfy system test.
>
> I'll take a look at it after Thanksgiving.
> 
> Somewhat related questions (sorry if totally unrelated):
> 
> Q1. shouldn't the input method be tied to the `Scene.focusOwner` property somehow?
> Q2. given the fact that there could be only one active IM in the application, shouldn't there be a static `currentInputFocusOwner` property somewhere?

@andy-goryachev-oracle I'll answer your questions in reverse order.

> Q2. given the fact that there could be only one active IM in the application, shouldn't there be a static
> currentInputFocusOwner property somewhere?

It's better to think that there's a separate IM associated with each operating system window but the OS only shows one at any time. That's the way the operating system API's work.

There hasn't been any reason to track this inside JavaFX. Normally the OS tracks which Scene has focus and we track which Node is the focusOwner in that Scene and that's all the bookkeeping we need. Things only get complicated with PopupWindows.

> Q1. shouldn't the input method be tied to the Scene.focusOwner property somehow?

Normally we do connect the input method with the Scene.focusOwner. But when PopupWindows are open keyboard events from one peer window are distributed across multiple Scenes so there's more than one focusOwner we could connect the input method to. It's up to JavaFX to figure out which Scene's focusOwner is relevant.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2494958752

From angorya at openjdk.org  Fri Nov 22 23:59:29 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 22 Nov 2024 23:59:29 GMT
Subject: RFR: 8342233: Regression: TextInputControl selection is backwards in
 RTL mode
Message-ID: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>

A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode.

The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`.

The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266).

---

I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167)

The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) .

-------------

Commit messages:
 - linux
 - take a screenshot
 - test
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.rtl.regression
 - whitespace
 - test
 - cleanup
 - Merge remote-tracking branch 'origin/master' into ag.rtl.regression.2
 - Merge remote-tracking branch 'origin/8342462.text.area.skin.cleanup' into ag.rtl.regression.2
 - ... and 6 more: https://git.openjdk.org/jfx/compare/3a8a5598...a4f295a3

Changes: https://git.openjdk.org/jfx/pull/1609/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342233
  Stats: 610 lines in 8 files changed: 559 ins; 23 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1609.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1609/head:pull/1609

PR: https://git.openjdk.org/jfx/pull/1609

From kizune at openjdk.org  Fri Nov 22 23:59:29 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 22 Nov 2024 23:59:29 GMT
Subject: RFR: 8342233: Regression: TextInputControl selection is backwards
 in RTL mode
In-Reply-To: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
References: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
Message-ID: <28TKE7uCaXZMvVqZ-F-8tBhQZ1s2R8sQDSIquHKabxQ=.091c851a-4f61-4634-830f-acfb9597abdb@github.com>

On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode.
> 
> The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`.
> 
> The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266).
> 
> ---
> 
> I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167)
> 
> The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) .

Marked as reviewed by kizune (Author).

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 840:

> 838:             Bounds bounds = paragraphNode.getBoundsInLocal();
> 839:             double paragraphViewY = paragraphNode.getLayoutY() + bounds.getMinY();
> 840:             if (

I really don't like empty opening brackets in conditions but i guess it is not explicitly prohibited. Aside of that fix looks reasonable.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1609#pullrequestreview-2417482719
PR Review Comment: https://git.openjdk.org/jfx/pull/1609#discussion_r1830536693

From nlisker at openjdk.org  Sat Nov 23 02:13:24 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 23 Nov 2024 02:13:24 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
Message-ID: <q-EjSqS5XoJZkav5dadLW8yFZe4fjXeD5zYkFWIKlFk=.30df98ca-14c1-4af5-bd7a-bef5b1539102@github.com>

On Fri, 22 Nov 2024 16:36:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
>> 
>> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
>> 2. A utility class to produce warnings when first using an incubator module.
>> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
>> 
>> See PR #1617 for a sample module that is built on top of this PR's source branch.
>> 
>> This is almost ready to review. I will take it out of Draft in the next day or so.
>
> Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
>  - Remove call to doPrivileged
>  - 8309381: Support JavaFX incubator modules

I had a look (at v2). If this approach works then it's fine for now, but it repeats the sin of coupling configurations of (potentially) unrelated modules and will increase the build time for a normal build (at least it will from the looks of it). It can be fix as part of the cleanup, but I don't see an easy way to make it work "properly" with the current setup.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2495219142

From nlisker at openjdk.org  Sat Nov 23 10:11:58 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 23 Nov 2024 10:11:58 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
Message-ID: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>

Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).

Changes:
* Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
* Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
* Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
* Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

-------------

Commit messages:
 - Fix whitespaces
 - Remove unused parsing method
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/1647/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344906
  Stats: 97 lines in 1 file changed: 5 ins; 77 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1647.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1647/head:pull/1647

PR: https://git.openjdk.org/jfx/pull/1647

From nlisker at openjdk.org  Sat Nov 23 10:11:58 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 23 Nov 2024 10:11:58 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <4slo41HDah0I4DgxGJ5HnCZgF9_4K0zmb1QB7w4VvSo=.a575d14c-ab98-4e07-af95-240938751d3f@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

@kevinrushforth @johanvos Please review of assign reviewers.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1647#issuecomment-2495423604

From jvos at openjdk.org  Sat Nov 23 10:21:19 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 23 Nov 2024 10:21:19 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <q-EjSqS5XoJZkav5dadLW8yFZe4fjXeD5zYkFWIKlFk=.30df98ca-14c1-4af5-bd7a-bef5b1539102@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
 <q-EjSqS5XoJZkav5dadLW8yFZe4fjXeD5zYkFWIKlFk=.30df98ca-14c1-4af5-bd7a-bef5b1539102@github.com>
Message-ID: <tSdtHPVBnBxqh0Rxpik34S9Bm8I9VmF2YxBqvws43hU=.fd1012af-40b6-4bc9-8751-afa15d813a1d@github.com>

On Sat, 23 Nov 2024 02:10:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I had a look (at v2). If this approach works then it's fine for now, but it repeats the sin of coupling configurations of (potentially) unrelated modules and will increase the build time for a normal build (at least it will from the looks of it). It can be fix as part of the cleanup, but I don't see an easy way to make it work "properly" with the current setup.

I second that. Hence, I am ok with it as the build.gradle rehaul will probably take much more time, and the incubator module PR should not have to wait for that. It stresses the importancy of doing the "cleanup" (or modernization) of build.gradle, but I think we are all aware of that, so +1.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2495428844

From kcr at openjdk.org  Sat Nov 23 14:28:18 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 23 Nov 2024 14:28:18 GMT
Subject: RFR: 8341687: Memory leak in TableView after interacting with
 TableMenuButton [v2]
In-Reply-To: <2An5VleHG6haZsVCDo_V_oF5gzWhmRokNT1iFQ61CLw=.ac838c45-a76d-4a15-8f58-1d018330047b@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
 <30q7eNS-ExTgoYF1LQJzCoql-S0mb1BNTu4pnVQmuls=.7648cc29-d3de-4b72-aa6c-d8be4de84435@github.com>
 <PzWa4ynApWDBzn5Krptee-J-FYmLV8iEcH2bb6JISGw=.61b05514-9ecc-4f82-8334-efb1136d624c@github.com>
 <G1KELuJFUDkbEIczncnJCW4o0IC7UwrtImziI6f2nlg=.e07c5e3a-c7d0-4083-8e75-6f8b550ef1c1@github.com>
 <WdCmVGvNWjG0AeerwOYwHKmQXv50-3a8oe77XddP4js=.1e30fd9c-de26-4858-8550-f2af8ee2e2b8@github.com>
 <ijtXBYo4z1RQ0V0MKx5RoRLaPOmOEFqMUQMbeiHMOXw=.f5567375-f63e-494b-8aee-ccbfecec75de@github.com>
 <2An5VleHG6haZsVCDo_V_oF5gzWhmRokNT1iFQ61CLw=.ac838c45-a76d-4a15-8f58-1d018330047b@github.com>
Message-ID: <IBinGBaviAr9vtR5UVo1XtZ2myYgeFOnKVYoCeSpUGg=.9c46f0c5-44f8-4537-8244-6f4aa1077156@github.com>

On Fri, 22 Nov 2024 21:33:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I'd review that!  The only question is how to do RT- efficiently, so it can be easily reviewed (without going through manually copying and pasting every id)...
>
> It would be pretty easy to do it with a JIRA REST query: Given an input list of `RT-nnnn` bug IDs, produce the corresponding output list of `JDK-mmmmmmm` bug IDs. I'll volunteer to do this part of it.
> 
> Someone could then easily turn that into a script using `sed` to do the replacement.

I filed [JDK-8344899](https://bugs.openjdk.org/browse/JDK-8344899) to track the cleanup and attached a `grep.log` file of all occurrences of `"RT-[0-9]+"` and a `rt2jdk.txt` file with the mapping from `RT-nnnn` to `JDK-mmmmmmm`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1640#discussion_r1855202798

From mhanl at openjdk.org  Sat Nov 23 16:24:20 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 23 Nov 2024 16:24:20 GMT
Subject: Integrated: 8341687: Memory leak in TableView after interacting with
 TableMenuButton
In-Reply-To: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
References: <dBfVm299_HThWb3ApZdZbhRwPyTLz9WYT1r0VjiVT-k=.cdf1ca0f-aeca-4c08-8d11-1ee0873a8ebc@github.com>
Message-ID: <4aSky_4eJvYMkmFrMwaUaptx_fbOB5bLVrI9ukCkYig=.8cbae445-a754-42c6-bd71-9e7ebf14901d@github.com>

On Sat, 16 Nov 2024 00:58:47 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> There are multiple issues in the `TableMenu` logic that result in a memory leak.
> 
> The following problems are now fixed with this PR:
> - The listener, that is registered to the `col.visibleProperty()` was not weak nor was it ever unregistered
>    - The fix is to do pretty much the same that was already done with the `col.textProperty()` listener
> - The `col.visibleProperty()` and `col.textProperty()` where added again and again and again to the column when the columns changed (which happens when toggling the visibility).
>   - The fix is to add the listeners once - when the `MenuItem` is created. This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the whole listener logic is not run again for the column

This pull request has now been integrated.

Changeset: f0958683
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f0958683f63d6659fac94eee8ddc2d21519d53ff
Stats:     285 lines in 3 files changed: 267 ins; 14 del; 4 mod

8341687: Memory leak in TableView after interacting with TableMenuButton

Reviewed-by: angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1640

From kcr at openjdk.org  Sat Nov 23 17:00:21 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 23 Nov 2024 17:00:21 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <MVnCU4UbHYYzoRJXaav8HxaT6SiKHQjTwXGNAQEDB2M=.608d9240-5895-4891-a7a1-6ed278a9d0fb@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

At a quick glance, this looks good. I'll run it through our CI and do a few local tests early next week.

Reviewers: @kevinrushforth @johanvos

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1647#issuecomment-2495539841

From kcr at openjdk.org  Sat Nov 23 17:11:20 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 23 Nov 2024 17:11:20 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <q-EjSqS5XoJZkav5dadLW8yFZe4fjXeD5zYkFWIKlFk=.30df98ca-14c1-4af5-bd7a-bef5b1539102@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
 <q-EjSqS5XoJZkav5dadLW8yFZe4fjXeD5zYkFWIKlFk=.30df98ca-14c1-4af5-bd7a-bef5b1539102@github.com>
Message-ID: <5QWGCX-1ZbI4PnBRDORnTpJOMJnT9NkdPMwrmNngUzg=.ee92e132-10d9-427f-89d9-9eb0d9de2535@github.com>

On Sat, 23 Nov 2024 02:10:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
>>  - Remove call to doPrivileged
>>  - 8309381: Support JavaFX incubator modules
>
> I had a look (at v2). If this approach works then it's fine for now, but it repeats the sin of coupling configurations of (potentially) unrelated modules and will increase the build time for a normal build (at least it will from the looks of it). It can be fix as part of the cleanup, but I don't see an easy way to make it work "properly" with the current setup.

@nlisker @johanvos @andy-goryachev-oracle Thanks for taking a look. On further reflection, I prefer to stick with the version in _this_ PR, rather than doing something ad hoc for just the incubator modules (Andy recommended the same in [this comment on Draft PR v2](https://github.com/openjdk/jfx/pull/1646#pullrequestreview-2455643214)).

So I propose to integrate this PR "as is", and file a follow-up bug for further improvements, linking it to the overall Gradle modernization umbrella Task, [JDK-8344728](https://bugs.openjdk.org/browse/JDK-8344728).

I'll wait until at least Tuesday of next week to see if there are additional comments.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2495543060

From mhanl at openjdk.org  Sat Nov 23 23:48:00 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 23 Nov 2024 23:48:00 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
Message-ID: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>

This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.

As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.

Thanks to @kevinrushforth who provided the mapping!
I wrote a small Java program that replaces all the occurrences. This includes the following files:
- .`java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

-------------

Commit messages:
 - 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources

Changes: https://git.openjdk.org/jfx/pull/1648/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344899
  Stats: 1015 lines in 361 files changed: 0 ins; 1 del; 1014 mod
  Patch: https://git.openjdk.org/jfx/pull/1648.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1648/head:pull/1648

PR: https://git.openjdk.org/jfx/pull/1648

From mhanl at openjdk.org  Sat Nov 23 23:48:01 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 23 Nov 2024 23:48:01 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
In-Reply-To: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
Message-ID: <ThKqjLUus0wqcIe1_hTTm4OpbRXH5jCJgjLfga5Ba48=.38c6fb2c-84c0-4b87-8bda-6c7d518e1973@github.com>

On Sat, 23 Nov 2024 23:42:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
> 
> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
> 
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes the following files:
> - .`java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

apps/samples/Modena/src/main/java/modena/Modena.java line 177:

> 175:         stage.setScene(scene);
> 176:         stage.setTitle("Modena");
> 177: //        stage.setIconified(test); // TODO: Blocked by JMY-203

I'm not sure how to map this issue

apps/samples/Modena/src/main/java/modena/Modena.java line 295:

> 293:                     (Node)FXMLLoader.load(Modena.class.getResource("CombinationTest.fxml"))));
> 294: 
> 295:             // Customer example from bug report DTL-5561

I'm not sure how to map this issue

apps/samples/Modena/src/main/resources/modena/ScottSelvia.fxml line 42:

> 40: <?import javafx.scene.text.*?>
> 41: 
> 42: <!-- Customer test case from bug DTL-5561 -->

I'm not sure how to map this issue

modules/javafx.graphics/src/main/java/javafx/scene/paint/RadialGradient.java line 463:

> 461:     @Override public int hashCode() {
> 462:         // We should be able to just call focusAngle.hashCode(),
> 463:         // see JFXC-4247

I'm not sure how to map this issue

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1855298488
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1855298494
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1855298537
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1855298396

From lkostyra at openjdk.org  Mon Nov 25 07:48:55 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 25 Nov 2024 07:48:55 GMT
Subject: [jfx23u] RFR: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
Message-ID: <KD20k7J7ORnW9jEBtDb6vjKQmurlaakN0x7YSh27zno=.493bc22b-936a-4674-92d6-c76d580fc9a7@github.com>

Hi all,

This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.

Thanks!

-------------

Commit messages:
 - Backport fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

Changes: https://git.openjdk.org/jfx23u/pull/32/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=32&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333374
  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx23u/pull/32.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/32/head:pull/32

PR: https://git.openjdk.org/jfx23u/pull/32

From mhanl at openjdk.org  Mon Nov 25 10:28:23 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 25 Nov 2024 10:28:23 GMT
Subject: RFR: 8344367: Fix mistakes in FX API docs
In-Reply-To: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
References: <zCkOmg6YUO4ZfZRxxcuh5OkfpH-ppYODonwQbGDS-Pg=.fa233c96-48b9-49eb-864e-8e1fd640a3e0@github.com>
Message-ID: <XODz2M_HeqPUSMwoLq_glGIOkCRVElYVQP5s4Sdu4WI=.c2829cd9-109a-4df9-ba86-4c6247062f25@github.com>

On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> A batch of typo and grammar fixes that were found by the spellchecker.
> 
> Integration can wait until RDP 1/2.

The corrections look good to me.

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1642#pullrequestreview-2457975226

From crschnick at xpipe.io  Mon Nov 25 10:41:39 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 25 Nov 2024 11:41:39 +0100
Subject: Windows default font glyphs are rendered wrong on some systems
Message-ID: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io>

Hello,

for some of our users, the font glyphs of the default Windows font are 
wrong by an offset of +2. E.g. the letter D is rendered as F, the symbol 
- is rendered as /, and so on ... However, the glyph spacings and 
kernings are using the correct values for the original letter, only the 
actual glyph itself is wrong. This is happening on the latest 24-ea 
build on Windows 11, but also occurred on version 21 a while ago. I 
wasn't able to reproduce it myself, only some users were.

This has happened now for multiple users of our application, so I 
figured to report it (Didn't find this in the bug tracker).

Here is there issue, next to how it should look like:


(It is in danish because the user played around with the language 
settings to troubleshoot)

There was no explicit -fx-font set, so the application uses the default 
one. When the users change to using -fx-font: Roboto, which is bundled 
with our application, the glyphs are rendered normally. So this issue is 
specific to certain fonts.

If there's any additional information required, I can relay that request 
to our affected users.


Best
Christopher Schnick

(I resent this mail as it got stuck in the moderation queue for being 
too big due to me accidentally pasting the screenshot as a .bmp)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241125/99747d96/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.png
Type: image/png
Size: 81374 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241125/99747d96/s-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ls6xRvPGaI1BL10B.png
Type: image/png
Size: 69609 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241125/99747d96/Ls6xRvPGaI1BL10B-0001.png>

From azvegint at openjdk.org  Mon Nov 25 11:13:33 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 11:13:33 GMT
Subject: Integrated: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session
In-Reply-To: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
References: <ehCLwQ0KH0A_UFV4MsWU1i0MnDbBAq9Tl0M-GXymQvM=.1e152f73-272e-4216-b55e-c9866bebb2fa@github.com>
Message-ID: <SxPo5uN-huqEZjSaUMJYq8r32hO01ViJBdRDyS2dcyc=.56364128-e726-4282-94be-058132aef833@github.com>

On Fri, 15 Nov 2024 01:47:40 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is the FX counterpart of the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `b.`(aka crash prevention part)
> 
> It does not crash without the [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` part.
> 
> The crash prevention part  is the same for the JDK and JavaFX, except that this PR includes a test.
> 
> ---- 
> 
> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
> This is to reduce overhead in case of frequent consecutive screen captures.
> 
> When we perform a [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91) to close the session, we internally call [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
> 
> It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by  [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99) (please note that `This function can be called multiple times.`).
> 
> So the solution is not to call `pw_deinit` because we don't really need it, and it needs to be applied to both the JDK and JavaFX.
> 
> [jdk commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73) / [jfx commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
> 
> ----
> 
> The newly introduced test is disabled for now(as part  of [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it requires the fix on both the JavaFX and JDK sides.
> For the same reason `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java` and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are not enabled back.
> But if the JDK and JavaFX have the fixes, everything works fine.
> Testing in other different scenarios also looks good.

This pull request has now been integrated.

Changeset: 001f292e
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/001f292e9f6f31e903e1219ffbc84432bae5824b
Stats:     166 lines in 3 files changed: 160 ins; 6 del; 0 mod

8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session

Reviewed-by: kcr, lkostyra

-------------

PR: https://git.openjdk.org/jfx/pull/1639

From mhanl at openjdk.org  Mon Nov 25 12:26:21 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 25 Nov 2024 12:26:21 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified
In-Reply-To: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
Message-ID: <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>

On Mon, 21 Oct 2024 15:32:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When the initial value of a styleable property is not specified in a stylesheet, no transition is started:
> 
>     .button {
>         transition: -fx-opacity 1s;
>     }
>     
>     .button:hover {
>         -fx-opacity: 0.5;
>     }
> 
> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1.
> 
> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time.
> 
> The logic to detect this situation is currently as follows:
> 
>     // If this.origin == null, we're setting the value for the first time.
>     // No transition should be started in this case.
>     TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ?
>         NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null;
> 
> 
> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this:
> 
> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied:
> 1. The node was added to a scene graph
> 2. CSS processing was completed for a scene pulse

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 607:

> 605:      * CSS state (see {@link Node#initialCssState}.
> 606:      */
> 607:     private final Set<Node> clearInitialCssStateNodes = Collections.newSetFromMap(new IdentityHashMap<>());

why not use a normal `HashSet`? What advantage has this approach?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1856527311

From mstrauss at openjdk.org  Mon Nov 25 12:38:25 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 25 Nov 2024 12:38:25 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified
In-Reply-To: <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
 <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>
Message-ID: <UqMTicQMAvI-1QkSk5j5nsZRiKprT5KXWFQPRrbZYXs=.078932a8-dbe3-415d-956e-6d3e14d1cc2c@github.com>

On Mon, 25 Nov 2024 12:24:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> When the initial value of a styleable property is not specified in a stylesheet, no transition is started:
>> 
>>     .button {
>>         transition: -fx-opacity 1s;
>>     }
>>     
>>     .button:hover {
>>         -fx-opacity: 0.5;
>>     }
>> 
>> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1.
>> 
>> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time.
>> 
>> The logic to detect this situation is currently as follows:
>> 
>>     // If this.origin == null, we're setting the value for the first time.
>>     // No transition should be started in this case.
>>     TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ?
>>         NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null;
>> 
>> 
>> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this:
>> 
>> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied:
>> 1. The node was added to a scene graph
>> 2. CSS processing was completed for a scene pulse
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 607:
> 
>> 605:      * CSS state (see {@link Node#initialCssState}.
>> 606:      */
>> 607:     private final Set<Node> clearInitialCssStateNodes = Collections.newSetFromMap(new IdentityHashMap<>());
> 
> why not use a normal `HashSet`? What advantage has this approach?

`HashSet` uses `Object.equals`, which can be overridden by user code, and this would break the logic. It's the _instance_ that wants to be notified.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1856544027

From mhanl at openjdk.org  Mon Nov 25 12:48:24 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 25 Nov 2024 12:48:24 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified
In-Reply-To: <UqMTicQMAvI-1QkSk5j5nsZRiKprT5KXWFQPRrbZYXs=.078932a8-dbe3-415d-956e-6d3e14d1cc2c@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
 <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>
 <UqMTicQMAvI-1QkSk5j5nsZRiKprT5KXWFQPRrbZYXs=.078932a8-dbe3-415d-956e-6d3e14d1cc2c@github.com>
Message-ID: <YuJTFNb9HwFT-F5SAxExPgtJg8bqQrvrazlkUBcoT1I=.02cd9e27-6778-4080-b056-aad1987cab57@github.com>

On Mon, 25 Nov 2024 12:35:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 607:
>> 
>>> 605:      * CSS state (see {@link Node#initialCssState}.
>>> 606:      */
>>> 607:     private final Set<Node> clearInitialCssStateNodes = Collections.newSetFromMap(new IdentityHashMap<>());
>> 
>> why not use a normal `HashSet`? What advantage has this approach?
>
> `HashSet` uses `Object.equals`, which can be overridden by user code, and this would break the logic. It's the _instance_ that wants to be notified.

Good point, I never ever did that for `Node`s (and I don't know why I would need to), but you are right, it is indeed possible and therefore a possible scenario.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1856557026

From azvegint at openjdk.org  Mon Nov 25 13:41:52 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 13:41:52 GMT
Subject: [jfx23u] RFR: 8335469: [XWayland] crash when an AWT ScreenCast session
 overlaps with an FX ScreenCast session
Message-ID: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>

Hi all,

This pull request contains a backport of commit [001f292e](https://github.com/openjdk/jfx/commit/001f292e9f6f31e903e1219ffbc84432bae5824b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Alexander Zvegintsev on 25 Nov 2024 and was reviewed by Kevin Rushforth and Lukasz Kostyra.

Thanks!

-------------

Commit messages:
 - Backport 001f292e9f6f31e903e1219ffbc84432bae5824b

Changes: https://git.openjdk.org/jfx23u/pull/33/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=33&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335469
  Stats: 166 lines in 3 files changed: 160 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jfx23u/pull/33.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/33/head:pull/33

PR: https://git.openjdk.org/jfx23u/pull/33

From lkostyra at openjdk.org  Mon Nov 25 14:16:20 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 25 Nov 2024 14:16:20 GMT
Subject: [jfx23u] Integrated: 8333374: Cannot invoke
 "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
In-Reply-To: <KD20k7J7ORnW9jEBtDb6vjKQmurlaakN0x7YSh27zno=.493bc22b-936a-4674-92d6-c76d580fc9a7@github.com>
References: <KD20k7J7ORnW9jEBtDb6vjKQmurlaakN0x7YSh27zno=.493bc22b-936a-4674-92d6-c76d580fc9a7@github.com>
Message-ID: <dRusUhLxT42F_IgDrMZcr0E_goKu-1qNDbUTWpmQvRU=.e61c2129-a223-4562-9b1d-a59ca602e982@github.com>

On Mon, 25 Nov 2024 07:43:33 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fb06b1f8](https://github.com/openjdk/jfx/commit/fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Lukasz Kostyra on 10 Oct 2024 and was reviewed by Kevin Rushforth, Jose Pereda and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0d05cb17
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/0d05cb17e20df0f504bd6cf21e0e19d362364fe4
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8333374: Cannot invoke "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null

Backport-of: fb06b1f8e88d1c09cc8109ad3cb0ef5a5a754934

-------------

PR: https://git.openjdk.org/jfx23u/pull/32

From azvegint at openjdk.org  Mon Nov 25 14:38:05 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 14:38:05 GMT
Subject: [jfx23u] RFR: 8337827: [XWayland] Skip failing tests on Wayland
Message-ID: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>

Hi all,

This pull request contains a backport of commit [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The reason this backport is not clean is because the jfx23 does not have the `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java`. So this change is skipped now.

The commit being backported was authored by Alexander Zvegintsev on 15 Aug 2024 and was reviewed by Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - 8337827: [XWayland] Skip failing tests on Wayland

Changes: https://git.openjdk.org/jfx23u/pull/34/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=34&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337827
  Stats: 29 lines in 3 files changed: 23 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jfx23u/pull/34.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/34/head:pull/34

PR: https://git.openjdk.org/jfx23u/pull/34

From kcr at openjdk.org  Mon Nov 25 15:53:29 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 25 Nov 2024 15:53:29 GMT
Subject: [jfx23u] RFR: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
References: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
Message-ID: <hui7kcslGvmDFuf6Fx02pT1ipdsELZj5809nM-5whFc=.a2eec6b7-d97f-473b-b839-b3d9a54917cc@github.com>

On Mon, 25 Nov 2024 14:29:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The reason this backport is not clean is because the jfx23 does not have the `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java`. So this change is skipped now.
> 
> The commit being backported was authored by Alexander Zvegintsev on 15 Aug 2024 and was reviewed by Kevin Rushforth.
> 
> Thanks!

I presume you have run the tests? GHA builds aren't enabled for your repo, so I can't tell.

-------------

PR Comment: https://git.openjdk.org/jfx23u/pull/34#issuecomment-2498389916

From jhendrikx at openjdk.org  Mon Nov 25 16:11:22 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 25 Nov 2024 16:11:22 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified
In-Reply-To: <YuJTFNb9HwFT-F5SAxExPgtJg8bqQrvrazlkUBcoT1I=.02cd9e27-6778-4080-b056-aad1987cab57@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
 <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>
 <UqMTicQMAvI-1QkSk5j5nsZRiKprT5KXWFQPRrbZYXs=.078932a8-dbe3-415d-956e-6d3e14d1cc2c@github.com>
 <YuJTFNb9HwFT-F5SAxExPgtJg8bqQrvrazlkUBcoT1I=.02cd9e27-6778-4080-b056-aad1987cab57@github.com>
Message-ID: <G-h5Aw-xgMT8PkqOsN5_OC4UzZV5g5bi_aT-QDfSlAE=.63493587-b5bf-45f6-b1cb-7a2c9c9aebd1@github.com>

On Mon, 25 Nov 2024 12:45:43 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> `HashSet` uses `Object.equals`, which can be overridden by user code, and this would break the logic. It's the _instance_ that wants to be notified.
>
> Good point, I never ever did that for `Node`s (and I don't know why I would need to), but you are right, it is indeed possible and therefore a possible scenario.

I think this is overly cautious.  Overriding equals on a class that did not implement equals in a hierarchy you don't control  is not a very reasonable scenario.  You will not be able to call `super.equals` with reasonable results if the hierarchy did not implement it in the first place.  This is because there may be private data that you can't access for your equality comparison (and `Node` has lots of that).  We also use `WeakHashMap`s in several areas already with subtypes of `Node`s as keys (I found `Region`, `Parent` and `TreeView` being used as keys), so this kind of override should probably be documented as being unsupported on `Node`.

Perhaps it should even be made final so FX internals can rely on it being correct.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1856882523

From kcr at openjdk.org  Mon Nov 25 16:32:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 25 Nov 2024 16:32:22 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
In-Reply-To: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
Message-ID: <uQQDi4ghM36E6TU4FTTwWyOHQB_izO9zvzh9xmvZpuk=.47a997f2-5bb8-49dd-b04b-c9b6838f3acd@github.com>

On Sat, 23 Nov 2024 23:42:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
> 
> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
> 
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes the following files:
> - .`java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

I see you ran into a few non-RT bugs in the old Kenai JIRA instance. All of those should have been scrubbed a long time ago. There is no meaningful mapping for any of them. I no longer even have the ability to look in the old database (unless it was archived 9+ years ago when it was decommissioned).

* `JFXC-` was used for the old JavaFXScript compiler (back in the JavaFX 1.x time frame), and now completely irrelevant.
* `DTL-` was used for an old JavaFXScript-based design tool, the precursor of what eventually became Scene Builder
* `JMY-` was used for the JemmyFX test harness, which still exists in the [openjdk/jfx-tests](https://github.com/openjdk/jfx-tests) repo, but wouldn't have been used for any of the tests in the main jfx repo

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1648#issuecomment-2498490278

From kcr at openjdk.org  Mon Nov 25 16:52:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 25 Nov 2024 16:52:22 GMT
Subject: [jfx23u] RFR: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
References: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
Message-ID: <eefMuO4u4desCsM4ZZ5_9hyA2wUvtaj3ldg9kUx3OXs=.0c92d884-2289-4bb4-a147-1f62c41ac455@github.com>

On Mon, 25 Nov 2024 14:29:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The reason this backport is not clean is because the jfx23 does not have the `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java`. So this change is skipped now.
> 
> The commit being backported was authored by Alexander Zvegintsev on 15 Aug 2024 and was reviewed by Kevin Rushforth.
> 
> Thanks!

This looks good. I confirm that the only difference between the mainline patch and this patch is that `SRGBTest.java` doesn't exist in jfx23u (so that part of the patch is irrelevant).

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx23u/pull/34#pullrequestreview-2458986954

From azvegint at openjdk.org  Mon Nov 25 17:02:25 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 17:02:25 GMT
Subject: [jfx23u] RFR: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <hui7kcslGvmDFuf6Fx02pT1ipdsELZj5809nM-5whFc=.a2eec6b7-d97f-473b-b839-b3d9a54917cc@github.com>
References: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
 <hui7kcslGvmDFuf6Fx02pT1ipdsELZj5809nM-5whFc=.a2eec6b7-d97f-473b-b839-b3d9a54917cc@github.com>
Message-ID: <MaWg2DyhspXqQu6GrCvNFzQ7C9aDGah1XI2_gQV6SFg=.dc8a2f19-23ad-41f5-9341-22320667ab97@github.com>

On Mon, 25 Nov 2024 15:50:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I presume you have run the tests? GHA builds aren't enabled for your repo, so I can't tell.

Only locally, the `SwingNodeJDialogTest` passes on X11, and skips on Wayland

-------------

PR Comment: https://git.openjdk.org/jfx23u/pull/34#issuecomment-2498558112

From mstrauss at openjdk.org  Mon Nov 25 17:09:49 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 25 Nov 2024 17:09:49 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified [v2]
In-Reply-To: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
Message-ID: <0QqbwcJMpM7Egn5VX7z1FFGmUkbUWbSBS2nxFsc5HVE=.a8dbbb42-8b45-4bb2-a1d7-3c7a761e310e@github.com>

> When the initial value of a styleable property is not specified in a stylesheet, no transition is started:
> 
>     .button {
>         transition: -fx-opacity 1s;
>     }
>     
>     .button:hover {
>         -fx-opacity: 0.5;
>     }
> 
> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1.
> 
> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time.
> 
> The logic to detect this situation is currently as follows:
> 
>     // If this.origin == null, we're setting the value for the first time.
>     // No transition should be started in this case.
>     TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ?
>         NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null;
> 
> 
> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this:
> 
> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied:
> 1. The node was added to a scene graph
> 2. CSS processing was completed for a scene pulse

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  use HashSet instead of IdentityHashMap

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1607/files
  - new: https://git.openjdk.org/jfx/pull/1607/files/9acfc04a..261da3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1607&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1607&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1607.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1607/head:pull/1607

PR: https://git.openjdk.org/jfx/pull/1607

From mstrauss at openjdk.org  Mon Nov 25 17:49:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 25 Nov 2024 17:49:37 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified [v3]
In-Reply-To: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
Message-ID: <OrIfJLXqqTGin5EELKd7nwOjb-mi2mUS3-XZnl2huWM=.96f912e3-3a57-4312-8a91-6c3cb80a8a90@github.com>

> When the initial value of a styleable property is not specified in a stylesheet, no transition is started:
> 
>     .button {
>         transition: -fx-opacity 1s;
>     }
>     
>     .button:hover {
>         -fx-opacity: 0.5;
>     }
> 
> The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1.
> 
> The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time.
> 
> The logic to detect this situation is currently as follows:
> 
>     // If this.origin == null, we're setting the value for the first time.
>     // No transition should be started in this case.
>     TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ?
>         NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null;
> 
> 
> However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this:
> 
> A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied:
> 1. The node was added to a scene graph
> 2. CSS processing was completed for a scene pulse

Michael Strau? 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 branch 'master' into fixes/css-initial-value
 - use HashSet instead of IdentityHashMap
 - start transitions only when not in initial CSS state

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1607/files
  - new: https://git.openjdk.org/jfx/pull/1607/files/261da3b8..819952a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1607&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1607&range=01-02

  Stats: 13037 lines in 311 files changed: 4863 ins; 6082 del; 2092 mod
  Patch: https://git.openjdk.org/jfx/pull/1607.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1607/head:pull/1607

PR: https://git.openjdk.org/jfx/pull/1607

From mstrauss at openjdk.org  Mon Nov 25 17:49:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 25 Nov 2024 17:49:37 GMT
Subject: RFR: 8342703: CSS transition is not started when initial value was
 not specified [v3]
In-Reply-To: <G-h5Aw-xgMT8PkqOsN5_OC4UzZV5g5bi_aT-QDfSlAE=.63493587-b5bf-45f6-b1cb-7a2c9c9aebd1@github.com>
References: <lHCOqWcdnHPyH8i9Kl7f0__k9PN7YH3WyG4X9WtfoQ4=.045f6b7f-8733-4f53-847d-609de027ce45@github.com>
 <7gJYcy0Fy5ezuwPs7MjgDGqaJvXvzCn7Z6wrhFg5cIE=.3a32364c-6bf8-4c22-9d19-c380cfa2c85e@github.com>
 <UqMTicQMAvI-1QkSk5j5nsZRiKprT5KXWFQPRrbZYXs=.078932a8-dbe3-415d-956e-6d3e14d1cc2c@github.com>
 <YuJTFNb9HwFT-F5SAxExPgtJg8bqQrvrazlkUBcoT1I=.02cd9e27-6778-4080-b056-aad1987cab57@github.com>
 <G-h5Aw-xgMT8PkqOsN5_OC4UzZV5g5bi_aT-QDfSlAE=.63493587-b5bf-45f6-b1cb-7a2c9c9aebd1@github.com>
Message-ID: <cLNjjGNUjzHihMaW6cqrAmJPwO6JaBCGPLF4HTz6glA=.769a2c28-3efc-4b27-91fc-3db6e42b3cf7@github.com>

On Mon, 25 Nov 2024 16:07:41 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Good point, I never ever did that for `Node`s (and I don't know why I would need to), but you are right, it is indeed possible and therefore a possible scenario.
>
> I think this is overly cautious.  Overriding equals on a class that did not implement equals in a hierarchy you don't control  is not a very reasonable scenario.  You will not be able to call `super.equals` with reasonable results if the hierarchy did not implement it in the first place.  This is because there may be private data that you can't access for your equality comparison (and `Node` has lots of that).  We also use `WeakHashMap`s in several areas already with subtypes of `Node`s as keys (I found `Region`, `Parent` and `TreeView` being used as keys), so this kind of override should probably be documented as being unsupported on `Node`.
> 
> Perhaps it should even be made final so FX internals can rely on it being correct.

Makes sense. I think we should make `Node.equals()` final in this case.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1607#discussion_r1857061762

From azvegint at openjdk.org  Mon Nov 25 18:59:19 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 18:59:19 GMT
Subject: [jfx23u] Integrated: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
References: <krquKvnNuxVRa1zdNuDF4bJx_PkcnHcp6n_WNyKrI94=.ee5ede3b-52a4-4b70-98dc-db4dbf6822a2@github.com>
Message-ID: <5TY5y48eOmCEP3wu3nWGNwi2ou0crvzMmuBDyMwvehU=.b5a3e919-7b4f-4b90-ae96-45cc603b3411@github.com>

On Mon, 25 Nov 2024 14:29:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The reason this backport is not clean is because the jfx23 does not have the `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java`. So this change is skipped now.
> 
> The commit being backported was authored by Alexander Zvegintsev on 15 Aug 2024 and was reviewed by Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 07deed96
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/07deed961bc80e3a016dbf27d3a52f33ab060334
Stats:     29 lines in 3 files changed: 23 ins; 5 del; 1 mod

8337827: [XWayland] Skip failing tests on Wayland

Reviewed-by: kcr
Backport-of: 0ee74e185673fba03d490122d0560a181ebd6fb2

-------------

PR: https://git.openjdk.org/jfx23u/pull/34

From azvegint at openjdk.org  Mon Nov 25 19:25:36 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 19:25:36 GMT
Subject: [jfx23u] RFR: 8335469: [XWayland] crash when an AWT ScreenCast
 session overlaps with an FX ScreenCast session [v2]
In-Reply-To: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>
References: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>
Message-ID: <Wm7RZdDitr7XREENHi5UUS4gtIFPCuzkyP96CGFN3Wk=.7af52f9e-1fd1-49da-abe6-ff693cf8c36a@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [001f292e](https://github.com/openjdk/jfx/commit/001f292e9f6f31e903e1219ffbc84432bae5824b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Alexander Zvegintsev on 25 Nov 2024 and was reviewed by Kevin Rushforth and Lukasz Kostyra.
> 
> Thanks!

Alexander Zvegintsev 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 'master' into backport-azvegint-001f292e-master
 - Backport 001f292e9f6f31e903e1219ffbc84432bae5824b

-------------

Changes:
  - all: https://git.openjdk.org/jfx23u/pull/33/files
  - new: https://git.openjdk.org/jfx23u/pull/33/files/4d855b56..5e319fd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx23u&pr=33&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx23u&pr=33&range=00-01

  Stats: 38 lines in 5 files changed: 32 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jfx23u/pull/33.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/33/head:pull/33

PR: https://git.openjdk.org/jfx23u/pull/33

From azvegint at openjdk.org  Mon Nov 25 19:50:24 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 19:50:24 GMT
Subject: [jfx23u] RFR: 8335469: [XWayland] crash when an AWT ScreenCast
 session overlaps with an FX ScreenCast session [v2]
In-Reply-To: <Wm7RZdDitr7XREENHi5UUS4gtIFPCuzkyP96CGFN3Wk=.7af52f9e-1fd1-49da-abe6-ff693cf8c36a@github.com>
References: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>
 <Wm7RZdDitr7XREENHi5UUS4gtIFPCuzkyP96CGFN3Wk=.7af52f9e-1fd1-49da-abe6-ff693cf8c36a@github.com>
Message-ID: <Njkyk2aKTsQtKaEgbme_hZUa45KdEqIsJ9fde2VBbqI=.c188f667-3c10-4b38-a95b-487c06791671@github.com>

On Mon, 25 Nov 2024 19:25:36 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [001f292e](https://github.com/openjdk/jfx/commit/001f292e9f6f31e903e1219ffbc84432bae5824b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>> 
>> The commit being backported was authored by Alexander Zvegintsev on 25 Nov 2024 and was reviewed by Kevin Rushforth and Lukasz Kostyra.
>> 
>> Thanks!
>
> Alexander Zvegintsev 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 'master' into backport-azvegint-001f292e-master
>  - Backport 001f292e9f6f31e903e1219ffbc84432bae5824b

After merging changes from #34, the GHA builds was successfully completed.

As for local testing, the `SwingNodeJDialogTest` and `LinuxScreencastHangCrashTest` are passed on X11, and are skipped on Wayland as expected.

-------------

PR Comment: https://git.openjdk.org/jfx23u/pull/33#issuecomment-2498895951

From azvegint at openjdk.org  Mon Nov 25 20:06:22 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 25 Nov 2024 20:06:22 GMT
Subject: [jfx23u] Integrated: 8335469: [XWayland] crash when an AWT ScreenCast
 session overlaps with an FX ScreenCast session
In-Reply-To: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>
References: <AgWucWwZzRV6kAZXKyIWkEE6RvhoHsNa9cBf3yT6YDU=.dc187223-5b9b-4689-9fe8-a4104e1ce489@github.com>
Message-ID: <GaY3xgC-jrdopuQHcbUzTJOiuuatGZBsy-kdgqYXMoo=.fbc28b6f-2b09-4560-859c-fbcf1a2588a0@github.com>

On Mon, 25 Nov 2024 13:36:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [001f292e](https://github.com/openjdk/jfx/commit/001f292e9f6f31e903e1219ffbc84432bae5824b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Alexander Zvegintsev on 25 Nov 2024 and was reviewed by Kevin Rushforth and Lukasz Kostyra.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 35ab1678
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/35ab16786a0646540ed87996855353bb6ec8e222
Stats:     166 lines in 3 files changed: 160 ins; 6 del; 0 mod

8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session

Backport-of: 001f292e9f6f31e903e1219ffbc84432bae5824b

-------------

PR: https://git.openjdk.org/jfx23u/pull/33

From kcr at openjdk.org  Mon Nov 25 23:49:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 25 Nov 2024 23:49:41 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <YSQwvGlfOVugphPuXagHKx6qkADTOo38D7_3V3aHIl8=.ab53e2a8-1f53-41e4-8621-32609a05ac2b@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

All of my testing looks fine, including CI and local testing.

There is one error case where we will now fail with a less informative error message than we used to, but it is a corner case where JDK 8 is used (which hasn't worked for over 7 years), so I don't see it as a problem.

In current master, running with JDK 8 will fail with the following error:


* What went wrong:
Execution failed for task ':verifyJava'.
> FAIL: java version mismatch: JDK version (1.8.0_371) < minimum version (22)


With this patch, building with JDK 8 will fail with one of two different errors, depending on whether the JDK to run gradle is also JDK or is JDK 11 or higher:

Using JDK 21 to run gradle and setting `JDK_HOME` to JDK 8:


FAILURE: Build failed with an exception.

* Where:
Build file '/Users/kcr/dev/javafx/jfx-kcr/jfx/rt/build.gradle' line: 760

* What went wrong:
A problem occurred evaluating root project 'rt'.
> Invalid version string: '1.8.0_371-ea-85-b01'


Using JDK 8 to run gradle and compile JavaFX:


FAILURE: Build failed with an exception.

* Where:
Build file '/Users/kcr/dev/javafx/jfx-kcr/jfx/rt/build.gradle' line: 760

* What went wrong:
A problem occurred evaluating root project 'rt'.
> java/lang/Runtime$Version


The latter won't be possible in gradle 9 anyway (the JDK used to run gradle 9 will need to be >= 11), so even less of a concern.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1647#pullrequestreview-2459846971

From nlisker at openjdk.org  Tue Nov 26 06:32:44 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 26 Nov 2024 06:32:44 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <lRJf1FTXdWzKmZawhL0Btok4zZckEX_GrlKxasKqBG8=.9ba2adf4-b288-45c2-ba9c-f4317bc6d488@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

Yes, `Version` doesn't parse the old 1.x JDK formats. Since the build JDK needs to be up to date anyway, I didn't see it as a problem.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1647#issuecomment-2499772605

From mhanl at openjdk.org  Tue Nov 26 08:59:10 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 26 Nov 2024 08:59:10 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v2]
In-Reply-To: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
Message-ID: <Mb6cxqwM9IR53KoRDJWp-icRZiBp38gVfYJdRivklk8=.1211c5f2-a375-4457-8940-517171ed27fa@github.com>

> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
> 
> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
> 
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes the following files:
> - .`java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  8344899: Remove occurrences of old JIRA tickets
  
  Including:
  - JFXC
  - DTL
  - JMY

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1648/files
  - new: https://git.openjdk.org/jfx/pull/1648/files/d62a9623..d1bd4c83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=00-01

  Stats: 4 lines in 3 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1648.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1648/head:pull/1648

PR: https://git.openjdk.org/jfx/pull/1648

From kcr at openjdk.org  Tue Nov 26 13:24:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 13:24:45 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <lRJf1FTXdWzKmZawhL0Btok4zZckEX_GrlKxasKqBG8=.9ba2adf4-b288-45c2-ba9c-f4317bc6d488@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
 <lRJf1FTXdWzKmZawhL0Btok4zZckEX_GrlKxasKqBG8=.9ba2adf4-b288-45c2-ba9c-f4317bc6d488@github.com>
Message-ID: <dbgWvsDiQGA74cDHf57J5L3KDBdL7DO8aCbyW8cjF58=.89c61002-fec1-4cfb-ae78-08391e2fae36@github.com>

On Tue, 26 Nov 2024 06:30:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Since the build JDK needs to be up to date anyway, I didn't see it as a problem.

I don't see it as a problem, either.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1647#issuecomment-2500791518

From nlisker at openjdk.org  Tue Nov 26 16:08:24 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 26 Nov 2024 16:08:24 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
Message-ID: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>

Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.

There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/1649/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345063
  Stats: 44 lines in 2 files changed: 15 ins; 3 del; 26 mod
  Patch: https://git.openjdk.org/jfx/pull/1649.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1649/head:pull/1649

PR: https://git.openjdk.org/jfx/pull/1649

From kevin.rushforth at oracle.com  Tue Nov 26 17:03:18 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 26 Nov 2024 09:03:18 -0800
Subject: Result: New OpenJFX Reviewer: Lukasz Kostyra
Message-ID: <de86cf77-f698-4577-87be-871293c2b496@oracle.com>

Voting for Lukasz Kostyra [1] to OpenJFX Reviewer [2] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is 
sufficient to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#lkostyra
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050772.html


From kcr at openjdk.org  Tue Nov 26 17:15:59 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 17:15:59 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
In-Reply-To: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
Message-ID: <6dkDymKl_FGkd0RZtxQLGzRK97t61aC8FQ8a2BXiZUE=.77671d48-2931-47c2-b73e-6d646978af95@github.com>

On Tue, 26 Nov 2024 16:03:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
> 
> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.

The changes look good. I'll do a quick CI test build before approving.

build.properties line 123:

> 121: icu.version=74.2
> 122: antlr4.version=4.7.2
> 123: lucene.version=7.7.3

Minor: Add a (single) blank line at the end of this file?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1649#pullrequestreview-2462227460
PR Review Comment: https://git.openjdk.org/jfx/pull/1649#discussion_r1858943810

From kcr at openjdk.org  Tue Nov 26 18:01:07 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 18:01:07 GMT
Subject: RFR: 8338000: [macos] Remove GlassFullscreenWindow
In-Reply-To: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
References: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
Message-ID: <JpvmBZAb5zFQ5FSdFfDnsis5uCiFHEZ2zuHQaQ-GrZQ=.4beb21f8-a413-4d24-9cf1-0d872c507923@github.com>

On Sun, 17 Nov 2024 20:18:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

@andy-goryachev-oracle can you be the second reviewer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1641#issuecomment-2501599285

From kcr at openjdk.org  Tue Nov 26 18:05:04 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 18:05:04 GMT
Subject: RFR: 8342233: Regression: TextInputControl selection is backwards
 in RTL mode
In-Reply-To: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
References: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
Message-ID: <Y1-Te0CVm95eE2acjP6sBuoW0IYsFHZAr-CM3zVzhh8=.230e182c-e562-40a9-873f-10c7bf3bad16@github.com>

On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode.
> 
> The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`.
> 
> The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266).
> 
> ---
> 
> I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167)
> 
> The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) .

@lukostyra Can you be the "R"eviewer on this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1609#issuecomment-2501608037

From kcr at openjdk.org  Tue Nov 26 18:17:46 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 18:17:46 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
In-Reply-To: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
Message-ID: <Swfyr79H847QducmyTNvzYGXzESYkKKM_OZ44TdqE1s=.8ebd1c7e-674c-492b-bb19-73a8aab2cd44@github.com>

On Tue, 26 Nov 2024 16:03:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
> 
> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1649#pullrequestreview-2462371868

From nlisker at openjdk.org  Tue Nov 26 18:50:18 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 26 Nov 2024 18:50:18 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
 [v2]
In-Reply-To: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
Message-ID: <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>

> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
> 
> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Added EOF line

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1649/files
  - new: https://git.openjdk.org/jfx/pull/1649/files/15dd5a8f..df9ae398

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1649&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1649&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1649.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1649/head:pull/1649

PR: https://git.openjdk.org/jfx/pull/1649

From kcr at openjdk.org  Tue Nov 26 18:50:18 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 18:50:18 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
 [v2]
In-Reply-To: <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
 <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
Message-ID: <H3YalbTdkyMos87QJa_KGOyQnkxvmz9ZJO3GR6YWnAg=.649a1a68-c805-4dfd-9153-eadc414daf43@github.com>

On Tue, 26 Nov 2024 18:47:00 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
>> 
>> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added EOF line

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1649#pullrequestreview-2462431891

From kcr at openjdk.org  Tue Nov 26 18:53:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 18:53:45 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
 [v2]
In-Reply-To: <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
 <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
Message-ID: <9ubDJ2r9-WvF-GHueLnQXaJmaTDut0jFxaaHhrV0JYA=.dd35171d-74b4-422f-8274-eeadf0f9fbd9@github.com>

On Tue, 26 Nov 2024 18:50:18 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
>> 
>> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added EOF line

I recommend waiting the usual 24 hours to integrate in case others have comments.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1649#issuecomment-2501694593

From mhanl at openjdk.org  Tue Nov 26 20:24:45 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 26 Nov 2024 20:24:45 GMT
Subject: RFR: 8345063: Centralize version number of the Gradle build file
 [v2]
In-Reply-To: <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
 <UbMg919eskvlgWO_DBVQ3RPy27b5-oi2q9z2lcB4V6I=.86940091-7e6a-4205-a116-39bd35ae234a@github.com>
Message-ID: <4tGehk50nSuw09iq6CHKRlVA_voUSFqn3LmjCaYXasw=.fa411d8f-bc9a-4444-b6ef-3f64c98153d4@github.com>

On Tue, 26 Nov 2024 18:50:18 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
>> 
>> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added EOF line

I agree that this is a good idea and something I do as well in Maven and Gradle projects. Putting them in the `build.properties` is fine.
Changes look good to me.

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1649#pullrequestreview-2462598537

From kcr at openjdk.org  Tue Nov 26 21:48:46 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 21:48:46 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v4]
In-Reply-To: <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
Message-ID: <cdKc5F7qn_mhATWmUvNTyp9vQGEQzPGAYuDbGgoKS_A=.e36de1a1-e74c-491c-a075-9aacd699919e@github.com>

On Fri, 1 Nov 2024 23:39:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>  - add platform keys to javadoc
>  - Change reducedScrollBars to persistentScrollBars
>  - Add reducedScrollBars preference

Looks good. In addition to reviewing the code and the docs, I tested it on all platforms. On Linux I tested it on Ubuntu 24.04  and on a _very_ old 16.04. There is a minor bug on 16.04 (a warning printed), but it could be done as a follow-up if you prefer.

I reviewed the CSR, so it is ready to finalize.

modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 126:

> 124: 
> 125:         gboolean overlayScrolling = true;
> 126:         g_object_get(settings, "gtk-overlay-scrolling", &overlayScrolling, NULL);

This causes a warning to be printed during initialization on a very old Ubuntu system (16.04) when running any application:


GLib-GObject-WARNING **: g_object_get_valist: object class 'GtkSettings' has no property named 'gtk-overlay-scrolling'


I see from the docs that this setting was added in GTK 3.24.9. Perhaps a runtime check is in order? It could be done as a follow-up bug since it is just a warning. It correctly reports `GTK.overlay_scrolling=true` and `persistentScrollBars=false`.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1618#pullrequestreview-2462637438
PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1859201109

From mstrauss at openjdk.org  Tue Nov 26 22:46:22 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 26 Nov 2024 22:46:22 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v5]
In-Reply-To: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
Message-ID: <YtyvSaTA6rVTcJLwHmlWc8rHakUCuEmRUNMNcexcKXs=.afea51b8-4d93-45a7-9d7b-afd4d494b295@github.com>

> This PR adds another accessibility preference that is available on all supported desktop platforms:
> 
> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
> 
> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  check whether gtk-overlay-scrolling exists

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1618/files
  - new: https://git.openjdk.org/jfx/pull/1618/files/dc0eac58..1f194ce2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1618&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1618&range=03-04

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1618.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1618/head:pull/1618

PR: https://git.openjdk.org/jfx/pull/1618

From mstrauss at openjdk.org  Tue Nov 26 22:46:22 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 26 Nov 2024 22:46:22 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v4]
In-Reply-To: <cdKc5F7qn_mhATWmUvNTyp9vQGEQzPGAYuDbGgoKS_A=.e36de1a1-e74c-491c-a075-9aacd699919e@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <fzIJAOYTGwNwVhAEIzA87qQXAe8ukvHu6pq-WPPRDd4=.6402469c-cdcc-472c-8b3d-e7f524397335@github.com>
 <cdKc5F7qn_mhATWmUvNTyp9vQGEQzPGAYuDbGgoKS_A=.e36de1a1-e74c-491c-a075-9aacd699919e@github.com>
Message-ID: <imFz-SsfQObLDZrhttSFIlY20n9-HnTz4dVdSlKxYqM=.9487f560-b151-4f0f-b325-9eac25a9bd44@github.com>

On Tue, 26 Nov 2024 20:43:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>>  - add platform keys to javadoc
>>  - Change reducedScrollBars to persistentScrollBars
>>  - Add reducedScrollBars preference
>
> modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 126:
> 
>> 124: 
>> 125:         gboolean overlayScrolling = true;
>> 126:         g_object_get(settings, "gtk-overlay-scrolling", &overlayScrolling, NULL);
> 
> This causes a warning to be printed during initialization on a very old Ubuntu system (16.04) when running any application:
> 
> 
> GLib-GObject-WARNING **: g_object_get_valist: object class 'GtkSettings' has no property named 'gtk-overlay-scrolling'
> 
> 
> I see from the docs that this setting was added in GTK 3.24.9. Perhaps a runtime check is in order? It could be done as a follow-up bug since it is just a warning. It correctly reports `GTK.overlay_scrolling=true` and `persistentScrollBars=false`.

I've added a runtime check for the `gtk-overlay-scrolling` property.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1859323447

From kcr at openjdk.org  Tue Nov 26 22:47:44 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 26 Nov 2024 22:47:44 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v8]
In-Reply-To: <a1RYq163Pfw6_TB9BufjB0P7V263A2L0QOYbgsvkoh0=.2d367dcb-1e0e-4be4-acd0-fda0820d03c7@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
 <a1RYq163Pfw6_TB9BufjB0P7V263A2L0QOYbgsvkoh0=.2d367dcb-1e0e-4be4-acd0-fda0820d03c7@github.com>
Message-ID: <uQ2ZzSkULDhll84J0rPLVp_tpQYNBdMXpBhTp_MucM4=.49e5b611-6a5a-4823-bea5-f919036cf894@github.com>

On Sat, 9 Nov 2024 07:45:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead.
>> 
>> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)).
>> 
>> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into feature/sealed-classes
>  - Merge branch 'master' into feature/sealed-classes
>  - Merge branch 'master' into feature/sealed-classes
>  - Merge branch 'master' into feature/sealed-classes
>  - add comment
>  - Merge branch 'master' into feature/sealed-classes
>  - remove documentation
>  - Seal Node, Camera, LightBase, Shape, Shape3D

This looks good. I left one question about whether (or not) to throw `InternalError` on a null (this was a case of a runtime check that should no longer be possible).

I also left a question in the CSR about the two public classes (MediaView and SwingNode) that extend `AbstractNode`. They show up in the javadocs, even though they are inaccessible. I think this is OK, but wanted Joe's take on it.

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java line 66:

> 64: 
> 65:     protected static NodeHelper getHelper(Node node) {
> 66:         return nodeAccessor.getHelper(node);

Is it worth checking for null and throwing an internal error if it is?

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1556#pullrequestreview-2462711912
PR Review Comment: https://git.openjdk.org/jfx/pull/1556#discussion_r1859251468

From mstrauss at openjdk.org  Wed Nov 27 00:26:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 27 Nov 2024 00:26:16 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v6]
In-Reply-To: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
Message-ID: <g026qkSk0Y4TqE7QLrqR09UUiSqHF__1M-1ywwHLDyU=.47d90714-6208-4d70-8542-be8cfbd0772f@github.com>

> This PR adds another accessibility preference that is available on all supported desktop platforms:
> 
> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
> 
> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.

Michael Strau? 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 branch 'master' into feature/accessibility-hide-scrollbars
 - check whether gtk-overlay-scrolling exists
 - Merge branch 'master' into feature/accessibility-hide-scrollbars
 - add platform keys to javadoc
 - Change reducedScrollBars to persistentScrollBars
 - Add reducedScrollBars preference

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1618/files
  - new: https://git.openjdk.org/jfx/pull/1618/files/1f194ce2..6d44e280

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1618&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1618&range=04-05

  Stats: 7644 lines in 194 files changed: 4087 ins; 2699 del; 858 mod
  Patch: https://git.openjdk.org/jfx/pull/1618.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1618/head:pull/1618

PR: https://git.openjdk.org/jfx/pull/1618

From arapte at openjdk.org  Wed Nov 27 01:44:46 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 27 Nov 2024 01:44:46 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <9C5TOCM6pCkHH4CKHK38JbMeG0WCXKQ_tsh5anDxKOk=.11ae7662-f036-4bc3-a94d-cb70c487ae3d@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

LGTM, with a minor correction (shall re-approve, when changed).
It fails as expected if we use JDK older than `jfx.build.jdk.version`

Execution failed for task ':verifyJava'.
> FAIL: java version mismatch: JDK version (21.0.2+13-58) < minimum version (22+36)


logs are as expected:

java.runtime.version: 23+37-2369
java version: 23
java build number: 37
jdk.runtime.version: 23+37-2369
jdk version: 23
jdk build 37

build.gradle line 1488:

> 1486: logger.quiet("jdk.runtime.version: " + jdkVersionInfo)
> 1487: logger.quiet("jdk version: " + jdkVersionInfo.feature())
> 1488: logger.quiet("jdk build " + javaVersionInfo.build().orElse(0))

minor:  missing **:** after _jdk build_

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1647#pullrequestreview-2463372382
PR Review Comment: https://git.openjdk.org/jfx/pull/1647#discussion_r1859614813

From kizune at openjdk.org  Wed Nov 27 06:52:44 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 27 Nov 2024 06:52:44 GMT
Subject: RFR: 8342233: Regression: TextInputControl selection is backwards
 in RTL mode
In-Reply-To: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
References: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
Message-ID: <MyhNfmAaPdGU6UjIu-ugd6OIJXrlSmX-RZfhlKwCEk0=.a05d8c0a-e7a0-4187-a8dd-78ef044d597a@github.com>

On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode.
> 
> The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`.
> 
> The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266).
> 
> ---
> 
> I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167)
> 
> The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) .

Looks good.

-------------

Marked as reviewed by kizune (Author).

PR Review: https://git.openjdk.org/jfx/pull/1609#pullrequestreview-2464038823

From nlisker at openjdk.org  Wed Nov 27 10:35:18 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 27 Nov 2024 10:35:18 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file [v2]
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <p9UBQ2Tr3m6Ro58ZGn0_DwJCTY2KYwG5N6SMNsuIqfg=.4eb277ab-3edf-43dd-89ad-cbc2e10e5c4e@github.com>

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Add missing :

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1647/files
  - new: https://git.openjdk.org/jfx/pull/1647/files/a633abb3..3337f6c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1647&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1647&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1647.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1647/head:pull/1647

PR: https://git.openjdk.org/jfx/pull/1647

From mstrauss at openjdk.org  Wed Nov 27 12:26:46 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 27 Nov 2024 12:26:46 GMT
Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase,
 Shape, Shape3D [v8]
In-Reply-To: <uQ2ZzSkULDhll84J0rPLVp_tpQYNBdMXpBhTp_MucM4=.49e5b611-6a5a-4823-bea5-f919036cf894@github.com>
References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com>
 <a1RYq163Pfw6_TB9BufjB0P7V263A2L0QOYbgsvkoh0=.2d367dcb-1e0e-4be4-acd0-fda0820d03c7@github.com>
 <uQ2ZzSkULDhll84J0rPLVp_tpQYNBdMXpBhTp_MucM4=.49e5b611-6a5a-4823-bea5-f919036cf894@github.com>
Message-ID: <eK9jS6o4xOldcG6f_Sqp6th2iYV5IlABeiQG033nYUY=.94e37db8-4f35-4055-8fda-ed901b58f32c@github.com>

On Tue, 26 Nov 2024 21:29:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into feature/sealed-classes
>>  - Merge branch 'master' into feature/sealed-classes
>>  - Merge branch 'master' into feature/sealed-classes
>>  - Merge branch 'master' into feature/sealed-classes
>>  - add comment
>>  - Merge branch 'master' into feature/sealed-classes
>>  - remove documentation
>>  - Seal Node, Camera, LightBase, Shape, Shape3D
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java line 66:
> 
>> 64: 
>> 65:     protected static NodeHelper getHelper(Node node) {
>> 66:         return nodeAccessor.getHelper(node);
> 
> Is it worth checking for null and throwing an internal error if it is?

I think that would be unnecessarily verbose, and it doesn't seem like it would offer a benefit: as of now, this can't happen. Let's assume that the class hierarchy is changed in the future, such that `null` might be returned. This wouldn't result in a compile-time error. The exception would only be thrown when someone tries to acquire the `NodeHelper`, but in this case, we'd most likely get a NPE anyway.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1556#discussion_r1860568698

From kcr at openjdk.org  Wed Nov 27 13:16:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 27 Nov 2024 13:16:49 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v6]
In-Reply-To: <g026qkSk0Y4TqE7QLrqR09UUiSqHF__1M-1ywwHLDyU=.47d90714-6208-4d70-8542-be8cfbd0772f@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <g026qkSk0Y4TqE7QLrqR09UUiSqHF__1M-1ywwHLDyU=.47d90714-6208-4d70-8542-be8cfbd0772f@github.com>
Message-ID: <dft2Mj-6qKcKj37lxfkr9KIGW3tHEUJombMP2x29hDs=.4aa4eb7d-4670-4fff-a4b0-b0985e84c2d2@github.com>

On Wed, 27 Nov 2024 00:26:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds another accessibility preference that is available on all supported desktop platforms:
>> 
>> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars
>> 2. **macOS**: System Settings -> Appearance -> Show scroll bars
>> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars
>> 
>> When the OS setting is changed, all platforms report updates that can be observed in JavaFX.
>> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature.
>
> Michael Strau? 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 branch 'master' into feature/accessibility-hide-scrollbars
>  - check whether gtk-overlay-scrolling exists
>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>  - add platform keys to javadoc
>  - Change reducedScrollBars to persistentScrollBars
>  - Add reducedScrollBars preference

The warning is gone on my Ubuntu 16.04 system. I note that the `GTK.overlay_scrolling` preference is not reported on that system (which seems fine) and that the `persistentScrollBarsProperty` is always `false`. Everything still works as expected on systems with a newer GTK.

modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 125:

> 123:         putBoolean(env, prefs, "GTK.enable_animations", enableAnimations);
> 124: 
> 125:         if (g_object_class_find_property(G_OBJECT_GET_CLASS(settings), "gtk-overlay-scrolling")) {

Looks good, presuming that we want the property to be absent on systems that don't support this setting.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1618#pullrequestreview-2464979642
PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1860633975

From kcr at openjdk.org  Wed Nov 27 13:17:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 27 Nov 2024 13:17:47 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file [v2]
In-Reply-To: <p9UBQ2Tr3m6Ro58ZGn0_DwJCTY2KYwG5N6SMNsuIqfg=.4eb277ab-3edf-43dd-89ad-cbc2e10e5c4e@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
 <p9UBQ2Tr3m6Ro58ZGn0_DwJCTY2KYwG5N6SMNsuIqfg=.4eb277ab-3edf-43dd-89ad-cbc2e10e5c4e@github.com>
Message-ID: <HInDdeCdkrj0_zghRdOCJ3OtwDsf3RWLogecfQq20GI=.59e84a08-8f74-4164-8b19-1f1ff20c05ab@github.com>

On Wed, 27 Nov 2024 10:35:18 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
>> 
>> Changes:
>> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
>> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
>> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
>> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing :

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1647#pullrequestreview-2464993388

From arapte at openjdk.org  Wed Nov 27 13:29:47 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 27 Nov 2024 13:29:47 GMT
Subject: RFR: 8344906: Simplify Java version parsing in the build file [v2]
In-Reply-To: <p9UBQ2Tr3m6Ro58ZGn0_DwJCTY2KYwG5N6SMNsuIqfg=.4eb277ab-3edf-43dd-89ad-cbc2e10e5c4e@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
 <p9UBQ2Tr3m6Ro58ZGn0_DwJCTY2KYwG5N6SMNsuIqfg=.4eb277ab-3edf-43dd-89ad-cbc2e10e5c4e@github.com>
Message-ID: <UAS4Hdl0oD8_dad78IuXULu5U7CvnU3t8BJ_k33yXfo=.3d74c73d-4293-4b34-a086-161abf83c201@github.com>

On Wed, 27 Nov 2024 10:35:18 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
>> 
>> Changes:
>> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
>> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
>> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
>> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing :

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1647#pullrequestreview-2465026942

From mstrauss at openjdk.org  Wed Nov 27 13:52:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 27 Nov 2024 13:52:52 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v6]
In-Reply-To: <dft2Mj-6qKcKj37lxfkr9KIGW3tHEUJombMP2x29hDs=.4aa4eb7d-4670-4fff-a4b0-b0985e84c2d2@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <g026qkSk0Y4TqE7QLrqR09UUiSqHF__1M-1ywwHLDyU=.47d90714-6208-4d70-8542-be8cfbd0772f@github.com>
 <dft2Mj-6qKcKj37lxfkr9KIGW3tHEUJombMP2x29hDs=.4aa4eb7d-4670-4fff-a4b0-b0985e84c2d2@github.com>
Message-ID: <zI537YZgt1KELOpJi4j--cZhJn7P1NS6GNmsV9OTO0k=.94a17b01-b601-4e5f-a557-2b472a92974c@github.com>

On Wed, 27 Nov 2024 13:09:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>>  - check whether gtk-overlay-scrolling exists
>>  - Merge branch 'master' into feature/accessibility-hide-scrollbars
>>  - add platform keys to javadoc
>>  - Change reducedScrollBars to persistentScrollBars
>>  - Add reducedScrollBars preference
>
> modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 125:
> 
>> 123:         putBoolean(env, prefs, "GTK.enable_animations", enableAnimations);
>> 124: 
>> 125:         if (g_object_class_find_property(G_OBJECT_GET_CLASS(settings), "gtk-overlay-scrolling")) {
> 
> Looks good, presuming that we want the property to be absent on systems that don't support this setting.

Yes, a property that isn't available shouldn't be included in the preferences map. We've documented that in `Platform.Preferences`:

     * The preferences that are reported by the platform may be dependent on the operating system version
     * and its current configuration, so applications should not assume that a particular preference is
     * always available.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1860698822

From kcr at openjdk.org  Wed Nov 27 13:56:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 27 Nov 2024 13:56:45 GMT
Subject: RFR: 8343336: Add persistentScrollBars preference [v6]
In-Reply-To: <zI537YZgt1KELOpJi4j--cZhJn7P1NS6GNmsV9OTO0k=.94a17b01-b601-4e5f-a557-2b472a92974c@github.com>
References: <hDgLSyUpxLDBiPfasx-BOg5IxH86Sjr77IOw6NSLr84=.3833e035-f9f3-4177-8af7-366bb68741ed@github.com>
 <g026qkSk0Y4TqE7QLrqR09UUiSqHF__1M-1ywwHLDyU=.47d90714-6208-4d70-8542-be8cfbd0772f@github.com>
 <dft2Mj-6qKcKj37lxfkr9KIGW3tHEUJombMP2x29hDs=.4aa4eb7d-4670-4fff-a4b0-b0985e84c2d2@github.com>
 <zI537YZgt1KELOpJi4j--cZhJn7P1NS6GNmsV9OTO0k=.94a17b01-b601-4e5f-a557-2b472a92974c@github.com>
Message-ID: <F03wXG0xHqofUqon99VLCWNg0QbuJflkoXUKYtz3Lgk=.e2c9d30a-6876-42c6-acdf-1d72b9c51553@github.com>

On Wed, 27 Nov 2024 13:50:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 125:
>> 
>>> 123:         putBoolean(env, prefs, "GTK.enable_animations", enableAnimations);
>>> 124: 
>>> 125:         if (g_object_class_find_property(G_OBJECT_GET_CLASS(settings), "gtk-overlay-scrolling")) {
>> 
>> Looks good, presuming that we want the property to be absent on systems that don't support this setting.
>
> Yes, a property that isn't available shouldn't be included in the preferences map. We've documented that in `Platform.Preferences`:
> 
>      * The preferences that are reported by the platform may be dependent on the operating system version
>      * and its current configuration, so applications should not assume that a particular preference is
>      * always available.

Yes, so this is fine.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1618#discussion_r1860705373

From lkostyra at openjdk.org  Wed Nov 27 14:24:45 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 27 Nov 2024 14:24:45 GMT
Subject: RFR: 8342233: Regression: TextInputControl selection is backwards
 in RTL mode
In-Reply-To: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
References: <pVb5dJ9vg2qnanZPXel-FWh6V0_7u6S9wO_jVWcnz0o=.a15a3df9-cd0a-485f-ae6f-19bc34bfa7be@github.com>
Message-ID: <gpVfPD_LDL6js9KZRp5pzI7fzBRojU0m9OFrLrJV5x4=.29b413b2-04a1-42d0-950d-bdccf54d0990@github.com>

On Fri, 25 Oct 2024 22:00:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode.
> 
> The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`.
> 
> The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266).
> 
> ---
> 
> I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167)
> 
> The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) .

In general looks good, I left one minor question and in the meantime I'll verify this on my Windows machine

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 831:

> 829:     protected int getInsertionPoint(double x, double y) {
> 830:         TextArea textArea = getSkinnable();
> 831:         Text n = getTextNode();

What's the reason for the name change `paragraphNode -> n`?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1609#pullrequestreview-2465158454
PR Review Comment: https://git.openjdk.org/jfx/pull/1609#discussion_r1860745038

From nlisker at openjdk.org  Wed Nov 27 14:32:44 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 27 Nov 2024 14:32:44 GMT
Subject: Integrated: 8344906: Simplify Java version parsing in the build file
In-Reply-To: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
References: <LRr4dg0JIHxWY54REnTpdKmfVQ4gXfP0akwmn7_IiJU=.03d95ca5-ceb2-4901-9a4c-f43484b2805b@github.com>
Message-ID: <xyClm10n-yC85VI9UKyVV_-ja84YFyh4_dtRK6yB8T8=.abc1e134-6f67-4184-bf48-03df704671d0@github.com>

On Sat, 23 Nov 2024 09:22:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replaces the manual versions handling with [Version](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Runtime.Version.html).
> 
> Changes:
> * Removed the methods `parseJavaVersion(String)`, `parseJdkVersion(String)` and `compareJdkVersion(String, String)`, and replaced them with `Version.parse` and `Version.compareTo` methods.
> * Removed the build properties of the Java version on which the Gradle build runs because they are only used for logging. Replaced with logging them directly. Note that Gradle logs by itself the info of the runtime it uses, so there's no need to logs these manually.
> * Simplified the build JDK version by working directly with `Version` instead of a `String`. This allows to store less build properties. Also used try-with-resources to close the stream. Note that the whole build JDK manual invocation hack should be replaced with the Java Toolchain.
> * Simplified the `verifyJava` task, which could also be replaced with built-in Gradle tools.

This pull request has now been integrated.

Changeset: 4af67c12
Author:    Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4af67c1286f119a967e2758ab373c1a625843308
Stats:     97 lines in 1 file changed: 5 ins; 77 del; 15 mod

8344906: Simplify Java version parsing in the build file

Reviewed-by: kcr, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1647

From kcr at openjdk.org  Wed Nov 27 14:55:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 27 Nov 2024 14:55:47 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v2]
In-Reply-To: <Mb6cxqwM9IR53KoRDJWp-icRZiBp38gVfYJdRivklk8=.1211c5f2-a375-4457-8940-517171ed27fa@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <Mb6cxqwM9IR53KoRDJWp-icRZiBp38gVfYJdRivklk8=.1211c5f2-a375-4457-8940-517171ed27fa@github.com>
Message-ID: <--JiAqBUQEWdu1C3WrHvD03b-2_fvpKqARS99vAmicY=.bf0b8692-44ab-4eff-9a5f-9ce3c40fba44@github.com>

On Tue, 26 Nov 2024 08:59:10 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
>> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>> 
>> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
>> 
>> Thanks to @kevinrushforth who provided the mapping!
>> I wrote a small Java program that replaces all the occurrences. This includes the following files:
>> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344899: Remove occurrences of old JIRA tickets
>   
>   Including:
>   - JFXC
>   - DTL
>   - JMY

Looks good except for a few changes in `StylesheetTest.java` where the `RT-nnnnn` refers to a filename and thus should be reverted.

modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 468:

> 466: 
> 467:         try {
> 468:             // Make sure JDK-8123343.css can be parsed, serialized and deserialized with the current code,

This refers to the name of a file, so should be reverted.

modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 487:

> 485: 
> 486:     @Test public void testRT_30953_deserialize_from_v4() {
> 487:         // JDK-8123343-v4.bss was generated with version 4

Should be reverted.

modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 495:

> 493:     public void testRT_30953_deserialize_from_2_2_45() {
> 494: 
> 495:         // JDK-8123343-2.2.4bss was generated with javafx version 2.2.45 from 7u??

Should be reverted.

modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 503:

> 501:     public void testRT_30953_deserialize_from_2_2_4() {
> 502: 
> 503:         // JDK-8123343-2.2.4bss was generated with javafx version 2.2.4 from 7u10

Should be reverted.

modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 511:

> 509:     public void testRT_30953_deserialize_from_2_2_21() {
> 510: 
> 511:         // JDK-8123343-2.2.21.bss was generated with javafx version 2.2.21 from 7u21

Should be reverted.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1648#pullrequestreview-2465249299
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1860800966
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1860801569
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1860801776
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1860801975
PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1860802227

From nlisker at openjdk.org  Wed Nov 27 15:50:46 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 27 Nov 2024 15:50:46 GMT
Subject: RFR: 8309381: Support JavaFX incubator modules [v2]
In-Reply-To: <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
References: <jfxIIYkhQuYs0iyZMVzDL0NNAQjsCVBx2l5tOR_RHlw=.593cd49a-d4a0-4af9-914e-f41b94ba56ec@github.com>
 <dmrDGEYyznvXz-MsvtzHVBluKJt_a-8iTj1H9jS6PG4=.33c6dbdc-48fb-4aef-af05-ecbc77c9015a@github.com>
Message-ID: <zGG0QFgZkjPloeORODFaImSnDX8qGAKspbD_PCa3BjY=.36ad6f41-0670-42a7-9110-c6565d814c07@github.com>

On Fri, 22 Nov 2024 16:36:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following:
>> 
>> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules).
>> 2. A utility class to produce warnings when first using an incubator module.
>> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2.
>> 
>> See PR #1617 for a sample module that is built on top of this PR's source branch.
>> 
>> This is almost ready to review. I will take it out of Draft in the next day or so.
>
> Kevin Rushforth 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 branch 'master' into 8309381-incubator.dev
>  - Remove call to doPrivileged
>  - 8309381: Support JavaFX incubator modules

Alright, the changes are not big, so if you feel it's better to have them inside I'm fine with it. It's not going to be the make-or-break for the build file.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2504210940

From nlisker at openjdk.org  Wed Nov 27 17:44:43 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 27 Nov 2024 17:44:43 GMT
Subject: Integrated: 8345063: Centralize version number of the Gradle build
 file
In-Reply-To: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
References: <4_cvL8R_dZSR7v9651f-mICRWInn9OI4i3CyuspPt5s=.aeb73904-460f-4237-a71a-6db472f249a7@github.com>
Message-ID: <OM3_4IA-EoT0mNghMrWbBXdXVrEsdbvxDBt9GcHPiwg=.d076a660-f518-4362-8827-74f963ea3e8f@github.com>

On Tue, 26 Nov 2024 16:03:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Centralizes version numbers in a single place. This is not the best way of doing it in Gradle, but it's an improvement that will simplify other changes. I used the `build.properties` file because other versions are already written there.
> 
> There are other version numbers in the build file, but they are not attached directly to a dependency. Mostly libav ones. I decided not to touch them.

This pull request has now been integrated.

Changeset: f7566ad8
Author:    Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f7566ad8353cdabc3881648a29a416c99f71e7b7
Stats:     44 lines in 2 files changed: 15 ins; 3 del; 26 mod

8345063: Centralize version number of the Gradle build file

Reviewed-by: kcr, mhanl

-------------

PR: https://git.openjdk.org/jfx/pull/1649

From jpereda at openjdk.org  Wed Nov 27 22:58:18 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 27 Nov 2024 22:58:18 GMT
Subject: RFR: 8342461: Remove calls to doPrivileged in javafx.web/{android,
 ios}
Message-ID: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>

Removes `doPrivileged` remaining calls in the `javafx.web` module included in {android,ios} code.

-------------

Commit messages:
 - Remove calls to doPrivileged in javafx.web for android and ios

Changes: https://git.openjdk.org/jfx/pull/1651/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342461
  Stats: 110 lines in 7 files changed: 0 ins; 92 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1651.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1651/head:pull/1651

PR: https://git.openjdk.org/jfx/pull/1651

From kcr at openjdk.org  Wed Nov 27 23:19:43 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 27 Nov 2024 23:19:43 GMT
Subject: RFR: 8342461: Remove calls to doPrivileged in
 javafx.web/{android,ios}
In-Reply-To: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
References: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
Message-ID: <-2KxrHmOcQz7vL8Gz7cSBCIfuY2uT11QXhSsAoL9XvI=.9171ed5b-ec2a-4005-8d4b-4641a910599c@github.com>

On Wed, 27 Nov 2024 22:54:01 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Removes `doPrivileged` remaining calls in the `javafx.web` module included in {android,ios} code.

Looks good. Since I can't test it, @johanvos might want to review.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1651#pullrequestreview-2466076076

From jvos at openjdk.org  Thu Nov 28 07:56:47 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 28 Nov 2024 07:56:47 GMT
Subject: RFR: 8342461: Remove calls to doPrivileged in
 javafx.web/{android,ios}
In-Reply-To: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
References: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
Message-ID: <JsbzacGcxD8zYWzqHLApR55Xnib4CmIg-4cXecvRRU4=.54a8f88c-fc2a-4a4b-8411-47516712cdf4@github.com>

On Wed, 27 Nov 2024 22:54:01 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Removes `doPrivileged` remaining calls in the `javafx.web` module included in {android,ios} code.

Looks good.
There is much more cleanup work to do, but that is clearly not in scope for this PR.

-------------

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1651#pullrequestreview-2466976002

From jpereda at openjdk.org  Thu Nov 28 08:44:45 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 28 Nov 2024 08:44:45 GMT
Subject: Integrated: 8342461: Remove calls to doPrivileged in
 javafx.web/{android,ios}
In-Reply-To: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
References: <QIIPdeEgxTe1Rz6Ud3Hyn7g3A9NioGaov0vMGxQTPvU=.539e4d89-cc3c-419d-97dd-5eaea3f46bee@github.com>
Message-ID: <Htej2hawcpftxk-oBqTCniOk_KATF2vbME_tg5OweFA=.8e0ae4b6-0623-40f7-832b-56f7495e373f@github.com>

On Wed, 27 Nov 2024 22:54:01 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Removes `doPrivileged` remaining calls in the `javafx.web` module included in {android,ios} code.

This pull request has now been integrated.

Changeset: a45e33c1
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a45e33c1a4d8390eb1e6ec66977f453df71a009a
Stats:     110 lines in 7 files changed: 0 ins; 92 del; 18 mod

8342461: Remove calls to doPrivileged in javafx.web/{android,ios}

Reviewed-by: kcr, jvos

-------------

PR: https://git.openjdk.org/jfx/pull/1651

From mhanl at openjdk.org  Thu Nov 28 10:50:46 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 28 Nov 2024 10:50:46 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v2]
In-Reply-To: <--JiAqBUQEWdu1C3WrHvD03b-2_fvpKqARS99vAmicY=.bf0b8692-44ab-4eff-9a5f-9ce3c40fba44@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <Mb6cxqwM9IR53KoRDJWp-icRZiBp38gVfYJdRivklk8=.1211c5f2-a375-4457-8940-517171ed27fa@github.com>
 <--JiAqBUQEWdu1C3WrHvD03b-2_fvpKqARS99vAmicY=.bf0b8692-44ab-4eff-9a5f-9ce3c40fba44@github.com>
Message-ID: <VxvDIAPkS2usAnA-0SULspwcc4Mw1JVL8Gnf6y3Sn1I=.70db47c9-8850-4054-88c8-a6af68d77da8@github.com>

On Wed, 27 Nov 2024 14:49:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344899: Remove occurrences of old JIRA tickets
>>   
>>   Including:
>>   - JFXC
>>   - DTL
>>   - JMY
>
> modules/javafx.graphics/src/test/java/test/javafx/css/StylesheetTest.java line 468:
> 
>> 466: 
>> 467:         try {
>> 468:             // Make sure JDK-8123343.css can be parsed, serialized and deserialized with the current code,
> 
> This refers to the name of a file, so should be reverted.

Good catch! I checked this file manually, but somehow I missed those!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1648#discussion_r1861960017

From mhanl at openjdk.org  Thu Nov 28 12:52:33 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 28 Nov 2024 12:52:33 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v3]
In-Reply-To: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
Message-ID: <wCjkiU3eRWmFaPqN83pJaHzFw7dakTLAYO2l3tQjmBo=.a24298ac-c1f0-4459-aa0e-2420be8092ef@github.com>

> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
> 
> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
> 
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes the following files:
> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  8344899: Revert accidentally renamed test comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1648/files
  - new: https://git.openjdk.org/jfx/pull/1648/files/d1bd4c83..1e04e12b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1648.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1648/head:pull/1648

PR: https://git.openjdk.org/jfx/pull/1648

From mhanl at openjdk.org  Thu Nov 28 12:52:34 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 28 Nov 2024 12:52:34 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v2]
In-Reply-To: <--JiAqBUQEWdu1C3WrHvD03b-2_fvpKqARS99vAmicY=.bf0b8692-44ab-4eff-9a5f-9ce3c40fba44@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <Mb6cxqwM9IR53KoRDJWp-icRZiBp38gVfYJdRivklk8=.1211c5f2-a375-4457-8940-517171ed27fa@github.com>
 <--JiAqBUQEWdu1C3WrHvD03b-2_fvpKqARS99vAmicY=.bf0b8692-44ab-4eff-9a5f-9ce3c40fba44@github.com>
Message-ID: <ZeW4fg1YCdt1y1nTJUJxtUHbxo_TTlghgEAzRbbgLw0=.5680f97a-65e2-4dc5-b305-9a77b4d51c1b@github.com>

On Wed, 27 Nov 2024 14:52:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Looks good except for a few changes in `StylesheetTest.java` where the `RT-nnnnn` refers to a filename and thus should be reverted.

Checked the whole project with: `JDK-[\d]*.[\w]` and `JDK-[\d]*-`. No other occurrences found other than the one mentioned from you. Should be good now.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1648#issuecomment-2506045048

From mstrauss at openjdk.org  Thu Nov 28 14:07:54 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 28 Nov 2024 14:07:54 GMT
Subject: RFR: 8345188: Set :root pseudo-class on root node
Message-ID: <aRVG8CPL4g2M-Cfi2fns-GuPc47sWORzKjzlQBHGUFw=.8d750210-e10e-4163-a641-214fac106f5e@github.com>

The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes:
https://www.w3.org/TR/selectors-4/#the-root-pseudo

JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification.

-------------

Commit messages:
 - Set :root pseudo-class on sub-scene root node
 - Set :root pseudo-class on root node

Changes: https://git.openjdk.org/jfx/pull/1652/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345188
  Stats: 62 lines in 5 files changed: 55 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1652.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652

PR: https://git.openjdk.org/jfx/pull/1652

From mstrauss at openjdk.org  Thu Nov 28 14:21:44 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 28 Nov 2024 14:21:44 GMT
Subject: RFR: 8338000: [macos] Remove GlassFullscreenWindow
In-Reply-To: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
References: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
Message-ID: <9Uv0ZNbkKxzmLDZGKEtcKJ_XlOMRvemlx904mxYmD4M=.78cf399f-1db6-4361-9c3e-38f8482d878d@github.com>

On Sun, 17 Nov 2024 20:18:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

The code changes look good. I built and tested the changes, everything works as expected.

-------------

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1641#pullrequestreview-2468298959

From kcr at openjdk.org  Thu Nov 28 14:40:51 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 28 Nov 2024 14:40:51 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v3]
In-Reply-To: <wCjkiU3eRWmFaPqN83pJaHzFw7dakTLAYO2l3tQjmBo=.a24298ac-c1f0-4459-aa0e-2420be8092ef@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <wCjkiU3eRWmFaPqN83pJaHzFw7dakTLAYO2l3tQjmBo=.a24298ac-c1f0-4459-aa0e-2420be8092ef@github.com>
Message-ID: <bQ7DtPeReVDQTKeGPl0zgTFI2_AqbcvIm5DjQ9IbK4c=.18446206-860f-4211-a205-bf01d33464b1@github.com>

On Thu, 28 Nov 2024 12:52:33 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
>> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>> 
>> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
>> 
>> Thanks to @kevinrushforth who provided the mapping!
>> I wrote a small Java program that replaces all the occurrences. This includes the following files:
>> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344899: Revert accidentally renamed test comments

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1648#pullrequestreview-2468345014

From mfox at openjdk.org  Thu Nov 28 16:53:43 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 28 Nov 2024 16:53:43 GMT
Subject: Integrated: 8338000: [macos] Remove GlassFullscreenWindow
In-Reply-To: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
References: <_LLz7cIV5932c07zxnw8csd4jic1bc6sGXNy-QSihQo=.5f67fa62-e7a2-4fad-a020-75feb0cb1745@github.com>
Message-ID: <U4q8oPgQA1beg9O_C0ufi5kFVr8ln7HQ8NwIUtd2Z4I=.582328ba-0c40-45e6-92fa-c9f75d3cd347@github.com>

On Sun, 17 Nov 2024 20:18:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The GlassFullscreenWindow class hasn't been instantiated since applet support was removed (JDK-8201538). This PR removes the class and the one (unused) member variable of that type.

This pull request has now been integrated.

Changeset: bdfc3387
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bdfc33874a109f540f9ad126a62c90e3cf34de86
Stats:     223 lines in 11 files changed: 0 ins; 221 del; 2 mod

8338000: [macos] Remove GlassFullscreenWindow

Reviewed-by: kcr, mstrauss

-------------

PR: https://git.openjdk.org/jfx/pull/1641

From duke at openjdk.org  Thu Nov 28 19:04:43 2024
From: duke at openjdk.org (Twig6943)
Date: Thu, 28 Nov 2024 19:04:43 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v19]
In-Reply-To: <nyYiZgoDQYiswgo8P7l3lrUY_X9vTpGH232XdlHySww=.f047899c-5dad-45f5-bf92-a6db990ae540@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <nyYiZgoDQYiswgo8P7l3lrUY_X9vTpGH232XdlHySww=.f047899c-5dad-45f5-bf92-a6db990ae540@github.com>
Message-ID: <2MSx8An6NkoIwB1eqv4LU6tyNhdvGwYMc3M7DoYMLOE=.36c927d1-2e44-453b-866f-dcbe7054deae@github.com>

On Wed, 9 Oct 2024 13:27:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused externs
>  - Destroy DrawableInfo properly

Would be cool if this got merged. X is slowly dying and should be avoided if possible.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2496011158

From tsayao at openjdk.org  Thu Nov 28 19:14:45 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 28 Nov 2024 19:14:45 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v19]
In-Reply-To: <2MSx8An6NkoIwB1eqv4LU6tyNhdvGwYMc3M7DoYMLOE=.36c927d1-2e44-453b-866f-dcbe7054deae@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <nyYiZgoDQYiswgo8P7l3lrUY_X9vTpGH232XdlHySww=.f047899c-5dad-45f5-bf92-a6db990ae540@github.com>
 <2MSx8An6NkoIwB1eqv4LU6tyNhdvGwYMc3M7DoYMLOE=.36c927d1-2e44-453b-866f-dcbe7054deae@github.com>
Message-ID: <w44bhnfqPEkussj91QmykBy9g4PigYMRXC6pjSeYAEo=.b96fcdf5-fcb9-4f1c-8d85-41055bd84dbf@github.com>

On Sun, 24 Nov 2024 13:44:20 GMT, Twig6943 <duke at openjdk.org> wrote:

> Would be cool if this got merged. X is slowly dying and should be avoided if possible.

The Wayland backend is not implemented here, as it would be a significantly larger task.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2506666727

From duke at openjdk.org  Thu Nov 28 19:18:44 2024
From: duke at openjdk.org (Twig6943)
Date: Thu, 28 Nov 2024 19:18:44 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v19]
In-Reply-To: <w44bhnfqPEkussj91QmykBy9g4PigYMRXC6pjSeYAEo=.b96fcdf5-fcb9-4f1c-8d85-41055bd84dbf@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <nyYiZgoDQYiswgo8P7l3lrUY_X9vTpGH232XdlHySww=.f047899c-5dad-45f5-bf92-a6db990ae540@github.com>
 <2MSx8An6NkoIwB1eqv4LU6tyNhdvGwYMc3M7DoYMLOE=.36c927d1-2e44-453b-866f-dcbe7054deae@github.com>
 <w44bhnfqPEkussj91QmykBy9g4PigYMRXC6pjSeYAEo=.b96fcdf5-fcb9-4f1c-8d85-41055bd84dbf@github.com>
Message-ID: <HR6DzdtDmoPxboFHXEyDN_dot3n_BxQ0wJs_J6LIuqw=.5ecc2b5a-3652-44bc-ad07-16d4e8ac8630@github.com>

On Thu, 28 Nov 2024 19:11:39 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Would be cool if this got merged. X is slowly dying and should be avoided if possible.
>
>> Would be cool if this got merged. X is slowly dying and should be avoided if possible.
> 
> The Wayland backend is not implemented here, as it would be a significantly larger task.

@tsayao @Glavo linked me to this issue tho

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2506669930

From mhanl at openjdk.org  Fri Nov 29 09:24:31 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 29 Nov 2024 09:24:31 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v4]
In-Reply-To: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
Message-ID: <rbrHD_-5IqKsWGk_cxOsSzlUSJ4txrkT_x-XyMnqb_8=.7a304b75-0a2a-4c22-8c9b-2bf5dd977798@github.com>

> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
> 
> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
> 
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes the following files:
> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`

Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' of https://github.com/openjdk/jfx into 8344899-rt-to-jdk
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m
 - 8344899: Revert accidentally renamed test comments
 - 8344899: Remove occurrences of old JIRA tickets
   
   Including:
   - JFXC
   - DTL
   - JMY
 - 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources

-------------

Changes: https://git.openjdk.org/jfx/pull/1648/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1648&range=03
  Stats: 1012 lines in 361 files changed: 0 ins; 4 del; 1008 mod
  Patch: https://git.openjdk.org/jfx/pull/1648.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1648/head:pull/1648

PR: https://git.openjdk.org/jfx/pull/1648

From mhanl at openjdk.org  Fri Nov 29 09:24:33 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 29 Nov 2024 09:24:33 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v3]
In-Reply-To: <wCjkiU3eRWmFaPqN83pJaHzFw7dakTLAYO2l3tQjmBo=.a24298ac-c1f0-4459-aa0e-2420be8092ef@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <wCjkiU3eRWmFaPqN83pJaHzFw7dakTLAYO2l3tQjmBo=.a24298ac-c1f0-4459-aa0e-2420be8092ef@github.com>
Message-ID: <joIr6ML_pd3rBAyDpbRooINvbVFgZbsCchvsbLl4P4I=.553fc0ea-81d9-4741-b081-d338a541f39b@github.com>

On Thu, 28 Nov 2024 12:52:33 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
>> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>> 
>> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
>> 
>> Thanks to @kevinrushforth who provided the mapping!
>> I wrote a small Java program that replaces all the occurrences. This includes the following files:
>> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344899: Revert accidentally renamed test comments

Solved the merge conflict with `GlassView3D.m`.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1648#issuecomment-2507397413

From nlisker at openjdk.org  Fri Nov 29 17:11:23 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 29 Nov 2024 17:11:23 GMT
Subject: RFR: 8345261: Refactor the Dimension2D classes
Message-ID: <YrGqPSWSFSNx2H-1ZfkyrTILFMExj6q-_sfWlhzI-hQ=.782d35d8-01b7-417b-ae17-d824812b5c7e@github.com>

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.

-------------

Commit messages:
 - Revert static import wildcard use
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/1653/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345261
  Stats: 93 lines in 7 files changed: 5 ins; 70 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1653.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1653/head:pull/1653

PR: https://git.openjdk.org/jfx/pull/1653

From nlisker at gmail.com  Fri Nov 29 23:12:44 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 30 Nov 2024 01:12:44 +0200
Subject: Possible mistakes in com.sun.javafx.geom.AreaOp
Message-ID: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>

I came across a potential mistake in the class com.sun.javafx.geom.AreaOp.
It uses raw Vector types and while trying to add generic parameters there
for type safety, I got some conflicts.

In the method AreaOp::calculate, the arguments should be Vector<Curve> and
the return type should also be Vector<Curve>, but it returns a Vector
called 'edges'. 'edges' is passed to the 'addEdges' method that should
take Vector<Edge> and Vector<Curve>. This means that 'edges' is a
Vector<Edge> and not Vector<Curve>. Already a conflict.
Then it is passed to 'pruneEdges', which, if it takes and returns
Vector<Edge>, runs into a conflict with the return type: 'Vector ret' has
Curve added to it. If I try to return Vector<Curve> instead, then in the
'numedges < 2' check the input Vector can't be returned unless it's also
Vector<Curve>, which again causes a conflict in 'calculate'.

There are also 'toArray' calls that seem to not do anything, like in
'resolveLinks' (line 454) and in 'finalizeSubCurves' (429).

Can anyone who knows this part of the code take a look?

- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241130/ffbf8e89/attachment.htm>

From jhendrikx at openjdk.org  Sat Nov 30 06:09:44 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 30 Nov 2024 06:09:44 GMT
Subject: RFR: 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: <Q1WD2nbIinXmxTZWCDr9DDc1PSvnRhSN6fOi5LJMiOY=.888811f0-f7a0-4fe8-b1fe-b4fc4f221e2e@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.

Looks good

-------------

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1653#pullrequestreview-2470718984

From john.hendrikx at gmail.com  Sat Nov 30 07:24:44 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 30 Nov 2024 08:24:44 +0100
Subject: Possible mistakes in com.sun.javafx.geom.AreaOp
In-Reply-To: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>
References: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>
Message-ID: <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com>

Hi Nir,

I encountered that class before while doing raw warning clean-ups in
graphics (which were never integrated).

The problem IMHO is in the assignment in `calculate`:

edges = pruneEdges(edges);

This assignment is both confusing and unnecessary, and violates the
principle of re-using variables for different purposes.? Method
pruneEdges must return CURVES (the name even implies it -- remove
edges), and the debug code in this block even assumes it does (it
assigned `numcurves` to `edges.size()` then assumes that it contains
curves when converting to the array format):

Rewrite the code as follows and it will be much clearer:

publicVector<Curve>calculate(Vector<Curve> left, Vector<Curve> right) {

Vector<Edge> edges = newVector<>();

addEdges(edges, left, AreaOp.CTAG_LEFT);

addEdges(edges, right, AreaOp.CTAG_RIGHT);

Vector<Curve> curves = pruneEdges(edges);

if(false) {

System.out.println("result: ");

intnumcurves = curves.size();

Curve[] curvelist = (Curve[]) edges.toArray(newCurve[numcurves]);

for(inti = 0; i < numcurves; i++) {

System.out.println("curvelist["+i+"] = "+curvelist[i]);

}

}

returncurves;

}

Then the initial code?in `pruneEdges` is just plain wrong, and seems to
be an attempt at optimization done incorrectly by returning an existing
vector to save having to allocate a new one:

privateVector<Curve>pruneEdges(Vector<Edge> edges) {

intnumedges = edges.size();

if(numedges < 2) {

returnedges;

}

Method pruneEdges however is supposed to return a minimum set of curves
that enclose an area.? A single edge can't contribute any area. I'm
pretty sure that if you change the check to `numedges < 1` that if the
remaining code runs normally it would also come to that conclusion (it
would return an empty vector of curves).? So this "optimization" here is
doing the wrong thing by potentially returning a single edge instead of
always returning an empty curve vector.

Now, I'm pretty sure we'll never see this case in practice, due to other
checks being done (specifically the `getOrder() > 0` check when adding
edges) and the likely fact that there is always going to be a minimum of
2 curves being passed to `calculate.? Adding an assert or just modifying
the code,?and then running all tests may help verify this.? I believe
however that the code needs to be this:

privateVector<Curve>pruneEdges(Vector<Edge> edges) {

intnumedges = edges.size();

if(numedges < 2) {

returnnumedges == 0 ? (Vector<Curve>)(Vector<?>)edges : new Vector(); //
as a single edge can't encompass any area, a single edge also results in
no curves being returned

}

The reason why we do need to return a mutable Vector here is because the
classes using the return value of calculate assume that it is writable
and doesn't need copying.? The ugly double cast of edges is relatively
contained -- it is only casted when empty (to avoid creating another
vector instance), and it was created by this class so its under
control.? Always returning `new Vector()` would also work, but it may
perform a tiny bit slower in some cases (probably not measurable IMHO).

I suspect the entire class is copied from somewhere, as at the time
JavaFX was written using Vector while at the same time trying to do
these kinds of optimizations is odd to say the least.

--John


On 30/11/2024 00:12, Nir Lisker wrote:
> I came across a potential mistake in the
> class?com.sun.javafx.geom.AreaOp. It uses raw Vector types and while
> trying to add generic parameters there for type safety, I got some
> conflicts.
>
> In the method AreaOp::calculate, the arguments should be Vector<Curve>
> and the return type should also be Vector<Curve>, but it returns a
> Vector called 'edges'. 'edges' is passed to the 'addEdges' method that
> should take?Vector<Edge> and Vector<Curve>. This means that 'edges' is
> a Vector<Edge> and not Vector<Curve>. Already a conflict.
> Then it is passed to 'pruneEdges', which, if it takes and returns
> Vector<Edge>, runs into a conflict with the return type: 'Vector ret'
> has Curve added to it. If I try to return Vector<Curve> instead, then
> in the 'numedges < 2' check the input Vector can't be returned unless
> it's also Vector<Curve>, which again causes a conflict in 'calculate'.
>
> There are also 'toArray' calls that seem to not do anything, like in
> 'resolveLinks' (line 454) and in 'finalizeSubCurves' (429).
>
> Can?anyone who knows this part of the code take?a look?
>
> - Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241130/191ac6b1/attachment-0001.htm>

From nlisker at openjdk.org  Sat Nov 30 12:05:44 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 30 Nov 2024 12:05:44 GMT
Subject: RFR: 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: <yxAJ5USmgTxDh1f6fDoB2ZOXwDhyFUZXlpFnDno3Rrg=.24b94ea9-14a1-4867-ac28-cfbe31ffb821@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.

Thanks John. Because it's the weekend I'll wait until Monday evening with this.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2508938693

From kcr at openjdk.org  Sat Nov 30 13:53:44 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 30 Nov 2024 13:53:44 GMT
Subject: RFR: 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: <bAmQsk4wpU-YYJ6cSRax5dem0jg3xCyNs_9fg92SxLM=.da557d37-4436-4922-9e94-00863e3a2086@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.

@azvegint Can you take a quick look at this since you added the Dimension class as part of your initial Wayland Robot fix?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2508969153

From kcr at openjdk.org  Sat Nov 30 13:53:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 30 Nov 2024 13:53:45 GMT
Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources
 [v4]
In-Reply-To: <rbrHD_-5IqKsWGk_cxOsSzlUSJ4txrkT_x-XyMnqb_8=.7a304b75-0a2a-4c22-8c9b-2bf5dd977798@github.com>
References: <ozMYjBnfIINz6rNwjwmyUFTCd0auJAPV6CgjnwLVPeg=.26c8aa20-b4a3-4034-839f-f601048f9de2@github.com>
 <rbrHD_-5IqKsWGk_cxOsSzlUSJ4txrkT_x-XyMnqb_8=.7a304b75-0a2a-4c22-8c9b-2bf5dd977798@github.com>
Message-ID: <6m9Fj0wIVEYPRpq03r3Zz4QtM3zHUz6F2e-JGoHMXKo=.99217472-46d4-4baf-b5b7-f3990b6fd1af@github.com>

On Fri, 29 Nov 2024 09:24:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`.
>> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>> 
>> As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA.
>> 
>> Thanks to @kevinrushforth who provided the mapping!
>> I wrote a small Java program that replaces all the occurrences. This includes the following files:
>> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
>
> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8344899-rt-to-jdk
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m
>  - 8344899: Revert accidentally renamed test comments
>  - 8344899: Remove occurrences of old JIRA tickets
>    
>    Including:
>    - JFXC
>    - DTL
>    - JMY
>  - 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1648#pullrequestreview-2470908018

From tsayao at openjdk.org  Sat Nov 30 15:01:20 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 30 Nov 2024 15:01:20 GMT
Subject: RFR: 8344372: Setting width for TRANSPARENT Stage ->
 gtk_window_resize: assertion 'height > 0'
Message-ID: <WpwT4qEoRxK3PlNbS3_jBvfdgdI4b3vi8bFlK_EoDK8=.8b1070d8-485d-46f4-87c8-7a950893e395@github.com>

The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size.

-------------

Commit messages:
 - Fix 8344372

Changes: https://git.openjdk.org/jfx/pull/1654/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344372
  Stats: 118 lines in 2 files changed: 118 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1654.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654

PR: https://git.openjdk.org/jfx/pull/1654

From tsayao at openjdk.org  Sat Nov 30 15:12:23 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 30 Nov 2024 15:12:23 GMT
Subject: RFR: 8344372: Setting width for TRANSPARENT Stage ->
 gtk_window_resize: assertion 'height > 0' [v2]
In-Reply-To: <WpwT4qEoRxK3PlNbS3_jBvfdgdI4b3vi8bFlK_EoDK8=.8b1070d8-485d-46f4-87c8-7a950893e395@github.com>
References: <WpwT4qEoRxK3PlNbS3_jBvfdgdI4b3vi8bFlK_EoDK8=.8b1070d8-485d-46f4-87c8-7a950893e395@github.com>
Message-ID: <mhzE5PdmVI1onnH8MGTKA06Ad9sVwSj5zc-1PpEjUTg=.a49d0485-fcc8-41ed-94b8-ae02d3ce9e9e@github.com>

> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix test class name

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1654/files
  - new: https://git.openjdk.org/jfx/pull/1654/files/4e36b428..9dd6961f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1654.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654

PR: https://git.openjdk.org/jfx/pull/1654

From tsayao at openjdk.org  Sat Nov 30 16:14:22 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 30 Nov 2024 16:14:22 GMT
Subject: RFR: 8344372: Setting width for TRANSPARENT Stage ->
 gtk_window_resize: assertion 'height > 0' [v3]
In-Reply-To: <WpwT4qEoRxK3PlNbS3_jBvfdgdI4b3vi8bFlK_EoDK8=.8b1070d8-485d-46f4-87c8-7a950893e395@github.com>
References: <WpwT4qEoRxK3PlNbS3_jBvfdgdI4b3vi8bFlK_EoDK8=.8b1070d8-485d-46f4-87c8-7a950893e395@github.com>
Message-ID: <Rog9bXI7DJoYieTY0zdllsq7c3pgNdz2pcU37VtiHlA=.c1aa1b66-8382-460f-aefe-4739817ad0ce@github.com>

> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix test package

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1654/files
  - new: https://git.openjdk.org/jfx/pull/1654/files/9dd6961f..e74b18c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1654.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654

PR: https://git.openjdk.org/jfx/pull/1654

From nlisker at gmail.com  Sat Nov 30 16:57:34 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 30 Nov 2024 18:57:34 +0200
Subject: Possible mistakes in com.sun.javafx.geom.AreaOp
In-Reply-To: <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com>
References: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>
 <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com>
Message-ID: <CA+0ynh-g=vmUpeSJLK__EGy6=wL6D8OdQFPu-q14S5HDZHQqwA@mail.gmail.com>

I agree with your type analysis. However, I'm hesitant to change the logic
in regarding 'numedges' without someone who is familiar with the domain
taking a look; these sorts of computations often have non-obvious sides to
them.

I also think that the class was copied. The raw types usage suggests a 1.4
era. Vector itself suggests even earlier times, perhaps AWT. If the code
doesn't require thread synchronization, and I don't think it does, using
List could even speed it up a bit.

Do you have an idea about the needless 'toArray' calls? The return is not
captured and it doesn't have side effects. Maybe to check the types?

On Sat, Nov 30, 2024 at 10:25?AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Hi Nir,
>
> I encountered that class before while doing raw warning clean-ups in
> graphics (which were never integrated).
>
> The problem IMHO is in the assignment in `calculate`:
>
> edges = pruneEdges(edges);
>
> This assignment is both confusing and unnecessary, and violates the
> principle of re-using variables for different purposes.  Method pruneEdges
> must return CURVES (the name even implies it -- remove edges), and the
> debug code in this block even assumes it does (it assigned `numcurves` to
> `edges.size()` then assumes that it contains curves when converting to the
> array format):
>
> Rewrite the code as follows and it will be much clearer:
>
> public Vector<Curve> calculate(Vector<Curve> left, Vector<Curve> right) {
>
> Vector<Edge> edges = new Vector<>();
>
> addEdges(edges, left, AreaOp.CTAG_LEFT);
>
> addEdges(edges, right, AreaOp.CTAG_RIGHT);
>
> Vector<Curve> curves = pruneEdges(edges);
>
> if (false) {
>
> System.out.println("result: ");
>
> int numcurves = curves.size();
>
> Curve[] curvelist = (Curve[]) edges.toArray(new Curve[numcurves]);
>
> for (int i = 0; i < numcurves; i++) {
>
> System.out.println("curvelist["+i+"] = "+curvelist[i]);
>
> }
>
> }
>
> return curves;
>
> }
>
> Then the initial code in `pruneEdges` is just plain wrong, and seems to be
> an attempt at optimization done incorrectly by returning an existing vector
> to save having to allocate a new one:
>
> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>
> int numedges = edges.size();
>
> if (numedges < 2) {
>
> return edges;
>
> }
>
> Method pruneEdges however is supposed to return a minimum set of curves
> that enclose an area.  A single edge can't contribute any area. I'm pretty
> sure that if you change the check to `numedges < 1` that if the remaining
> code runs normally it would also come to that conclusion (it would return
> an empty vector of curves).  So this "optimization" here is doing the wrong
> thing by potentially returning a single edge instead of always returning an
> empty curve vector.
>
> Now, I'm pretty sure we'll never see this case in practice, due to other
> checks being done (specifically the `getOrder() > 0` check when adding
> edges) and the likely fact that there is always going to be a minimum of 2
> curves being passed to `calculate.  Adding an assert or just modifying the
> code, and then running all tests may help verify this.  I believe however
> that the code needs to be this:
>
> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>
> int numedges = edges.size();
>
> if (numedges < 2) {
>
> return numedges == 0 ? (Vector<Curve>)(Vector<?>)edges : new Vector(); //
> as a single edge can't encompass any area, a single edge also results in no
> curves being returned
>
> }
>
> The reason why we do need to return a mutable Vector here is because the
> classes using the return value of calculate assume that it is writable and
> doesn't need copying.  The ugly double cast of edges is relatively
> contained -- it is only casted when empty (to avoid creating another vector
> instance), and it was created by this class so its under control.  Always
> returning `new Vector()` would also work, but it may perform a tiny bit
> slower in some cases (probably not measurable IMHO).
>
> I suspect the entire class is copied from somewhere, as at the time JavaFX
> was written using Vector while at the same time trying to do these kinds of
> optimizations is odd to say the least.
>
> --John
>
>
> On 30/11/2024 00:12, Nir Lisker wrote:
>
> I came across a potential mistake in the class com.sun.javafx.geom.AreaOp.
> It uses raw Vector types and while trying to add generic parameters there
> for type safety, I got some conflicts.
>
> In the method AreaOp::calculate, the arguments should be Vector<Curve> and
> the return type should also be Vector<Curve>, but it returns a Vector
> called 'edges'. 'edges' is passed to the 'addEdges' method that should
> take Vector<Edge> and Vector<Curve>. This means that 'edges' is a
> Vector<Edge> and not Vector<Curve>. Already a conflict.
> Then it is passed to 'pruneEdges', which, if it takes and returns
> Vector<Edge>, runs into a conflict with the return type: 'Vector ret' has
> Curve added to it. If I try to return Vector<Curve> instead, then in the
> 'numedges < 2' check the input Vector can't be returned unless it's also
> Vector<Curve>, which again causes a conflict in 'calculate'.
>
> There are also 'toArray' calls that seem to not do anything, like in
> 'resolveLinks' (line 454) and in 'finalizeSubCurves' (429).
>
> Can anyone who knows this part of the code take a look?
>
> - Nir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241130/f89d960a/attachment-0001.htm>

From bourges.laurent at gmail.com  Sat Nov 30 17:43:22 2024
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 30 Nov 2024 18:43:22 +0100
Subject: Possible mistakes in com.sun.javafx.geom.AreaOp
In-Reply-To: <CA+0ynh-g=vmUpeSJLK__EGy6=wL6D8OdQFPu-q14S5HDZHQqwA@mail.gmail.com>
References: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>
 <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com>
 <CA+0ynh-g=vmUpeSJLK__EGy6=wL6D8OdQFPu-q14S5HDZHQqwA@mail.gmail.com>
Message-ID: <CAKjRUT4R9vOmckenVuseymnN3tywOkg1YxqyZei6LWhXJvez0A@mail.gmail.com>

Probably derived from java.awt.Area:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/geom/Area.java

Le sam. 30 nov. 2024, 17:59, Nir Lisker <nlisker at gmail.com> a ?crit :

> I agree with your type analysis. However, I'm hesitant to change the logic
> in regarding 'numedges' without someone who is familiar with the domain
> taking a look; these sorts of computations often have non-obvious sides to
> them.
>
> I also think that the class was copied. The raw types usage suggests a 1.4
> era. Vector itself suggests even earlier times, perhaps AWT. If the code
> doesn't require thread synchronization, and I don't think it does, using
> List could even speed it up a bit.
>
> Do you have an idea about the needless 'toArray' calls? The return is not
> captured and it doesn't have side effects. Maybe to check the types?
>
> On Sat, Nov 30, 2024 at 10:25?AM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> Hi Nir,
>>
>> I encountered that class before while doing raw warning clean-ups in
>> graphics (which were never integrated).
>>
>> The problem IMHO is in the assignment in `calculate`:
>>
>> edges = pruneEdges(edges);
>>
>> This assignment is both confusing and unnecessary, and violates the
>> principle of re-using variables for different purposes.  Method pruneEdges
>> must return CURVES (the name even implies it -- remove edges), and the
>> debug code in this block even assumes it does (it assigned `numcurves` to
>> `edges.size()` then assumes that it contains curves when converting to the
>> array format):
>>
>> Rewrite the code as follows and it will be much clearer:
>>
>> public Vector<Curve> calculate(Vector<Curve> left, Vector<Curve> right) {
>>
>> Vector<Edge> edges = new Vector<>();
>>
>> addEdges(edges, left, AreaOp.CTAG_LEFT);
>>
>> addEdges(edges, right, AreaOp.CTAG_RIGHT);
>>
>> Vector<Curve> curves = pruneEdges(edges);
>>
>> if (false) {
>>
>> System.out.println("result: ");
>>
>> int numcurves = curves.size();
>>
>> Curve[] curvelist = (Curve[]) edges.toArray(new Curve[numcurves]);
>>
>> for (int i = 0; i < numcurves; i++) {
>>
>> System.out.println("curvelist["+i+"] = "+curvelist[i]);
>>
>> }
>>
>> }
>>
>> return curves;
>>
>> }
>>
>> Then the initial code in `pruneEdges` is just plain wrong, and seems to
>> be an attempt at optimization done incorrectly by returning an existing
>> vector to save having to allocate a new one:
>>
>> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>>
>> int numedges = edges.size();
>>
>> if (numedges < 2) {
>>
>> return edges;
>>
>> }
>>
>> Method pruneEdges however is supposed to return a minimum set of curves
>> that enclose an area.  A single edge can't contribute any area. I'm pretty
>> sure that if you change the check to `numedges < 1` that if the remaining
>> code runs normally it would also come to that conclusion (it would return
>> an empty vector of curves).  So this "optimization" here is doing the wrong
>> thing by potentially returning a single edge instead of always returning an
>> empty curve vector.
>>
>> Now, I'm pretty sure we'll never see this case in practice, due to other
>> checks being done (specifically the `getOrder() > 0` check when adding
>> edges) and the likely fact that there is always going to be a minimum of 2
>> curves being passed to `calculate.  Adding an assert or just modifying the
>> code, and then running all tests may help verify this.  I believe however
>> that the code needs to be this:
>>
>> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>>
>> int numedges = edges.size();
>>
>> if (numedges < 2) {
>>
>> return numedges == 0 ? (Vector<Curve>)(Vector<?>)edges : new Vector();
>> // as a single edge can't encompass any area, a single edge also results in
>> no curves being returned
>>
>> }
>>
>> The reason why we do need to return a mutable Vector here is because the
>> classes using the return value of calculate assume that it is writable and
>> doesn't need copying.  The ugly double cast of edges is relatively
>> contained -- it is only casted when empty (to avoid creating another vector
>> instance), and it was created by this class so its under control.  Always
>> returning `new Vector()` would also work, but it may perform a tiny bit
>> slower in some cases (probably not measurable IMHO).
>>
>> I suspect the entire class is copied from somewhere, as at the time
>> JavaFX was written using Vector while at the same time trying to do these
>> kinds of optimizations is odd to say the least.
>>
>> --John
>>
>>
>> On 30/11/2024 00:12, Nir Lisker wrote:
>>
>> I came across a potential mistake in the
>> class com.sun.javafx.geom.AreaOp. It uses raw Vector types and while trying
>> to add generic parameters there for type safety, I got some conflicts.
>>
>> In the method AreaOp::calculate, the arguments should be Vector<Curve>
>> and the return type should also be Vector<Curve>, but it returns a Vector
>> called 'edges'. 'edges' is passed to the 'addEdges' method that should
>> take Vector<Edge> and Vector<Curve>. This means that 'edges' is a
>> Vector<Edge> and not Vector<Curve>. Already a conflict.
>> Then it is passed to 'pruneEdges', which, if it takes and returns
>> Vector<Edge>, runs into a conflict with the return type: 'Vector ret' has
>> Curve added to it. If I try to return Vector<Curve> instead, then in the
>> 'numedges < 2' check the input Vector can't be returned unless it's also
>> Vector<Curve>, which again causes a conflict in 'calculate'.
>>
>> There are also 'toArray' calls that seem to not do anything, like in
>> 'resolveLinks' (line 454) and in 'finalizeSubCurves' (429).
>>
>> Can anyone who knows this part of the code take a look?
>>
>> - Nir
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241130/1b7ca002/attachment.htm>

From nlisker at gmail.com  Sat Nov 30 17:51:50 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 30 Nov 2024 19:51:50 +0200
Subject: Possible mistakes in com.sun.javafx.geom.AreaOp
In-Reply-To: <CAKjRUT4R9vOmckenVuseymnN3tywOkg1YxqyZei6LWhXJvez0A@mail.gmail.com>
References: <CA+0ynh8C7UKkaiqVMh_UOAjwBy-hNROc9W71tguNRBfKTOWPjQ@mail.gmail.com>
 <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com>
 <CA+0ynh-g=vmUpeSJLK__EGy6=wL6D8OdQFPu-q14S5HDZHQqwA@mail.gmail.com>
 <CAKjRUT4R9vOmckenVuseymnN3tywOkg1YxqyZei6LWhXJvez0A@mail.gmail.com>
Message-ID: <CA+0ynh8YPMRFQZUnjSh7=dyNsrCC9V9H3z25_0QDMGx+=X+JmQ@mail.gmail.com>

You're right, these geometry classes were copied from AWT. Here is the
offending AreOp:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/geom/AreaOp.java
.

They generified their code at some point like John did. They also just
create a new vector in the 'numedges' check. I wonder why they kept Vector
though.

On Sat, Nov 30, 2024 at 7:43?PM Laurent Bourg?s <bourges.laurent at gmail.com>
wrote:

> Probably derived from java.awt.Area:
>
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/geom/Area.java
>
> Le sam. 30 nov. 2024, 17:59, Nir Lisker <nlisker at gmail.com> a ?crit :
>
>> I agree with your type analysis. However, I'm hesitant to change the
>> logic in regarding 'numedges' without someone who is familiar with the
>> domain taking a look; these sorts of computations often have non-obvious
>> sides to them.
>>
>> I also think that the class was copied. The raw types usage suggests a
>> 1.4 era. Vector itself suggests even earlier times, perhaps AWT. If the
>> code doesn't require thread synchronization, and I don't think it does,
>> using List could even speed it up a bit.
>>
>> Do you have an idea about the needless 'toArray' calls? The return is not
>> captured and it doesn't have side effects. Maybe to check the types?
>>
>> On Sat, Nov 30, 2024 at 10:25?AM John Hendrikx <john.hendrikx at gmail.com>
>> wrote:
>>
>>> Hi Nir,
>>>
>>> I encountered that class before while doing raw warning clean-ups in
>>> graphics (which were never integrated).
>>>
>>> The problem IMHO is in the assignment in `calculate`:
>>>
>>> edges = pruneEdges(edges);
>>>
>>> This assignment is both confusing and unnecessary, and violates the
>>> principle of re-using variables for different purposes.  Method pruneEdges
>>> must return CURVES (the name even implies it -- remove edges), and the
>>> debug code in this block even assumes it does (it assigned `numcurves` to
>>> `edges.size()` then assumes that it contains curves when converting to the
>>> array format):
>>>
>>> Rewrite the code as follows and it will be much clearer:
>>>
>>> public Vector<Curve> calculate(Vector<Curve> left, Vector<Curve> right)
>>> {
>>>
>>> Vector<Edge> edges = new Vector<>();
>>>
>>> addEdges(edges, left, AreaOp.CTAG_LEFT);
>>>
>>> addEdges(edges, right, AreaOp.CTAG_RIGHT);
>>>
>>> Vector<Curve> curves = pruneEdges(edges);
>>>
>>> if (false) {
>>>
>>> System.out.println("result: ");
>>>
>>> int numcurves = curves.size();
>>>
>>> Curve[] curvelist = (Curve[]) edges.toArray(new Curve[numcurves]);
>>>
>>> for (int i = 0; i < numcurves; i++) {
>>>
>>> System.out.println("curvelist["+i+"] = "+curvelist[i]);
>>>
>>> }
>>>
>>> }
>>>
>>> return curves;
>>>
>>> }
>>>
>>> Then the initial code in `pruneEdges` is just plain wrong, and seems to
>>> be an attempt at optimization done incorrectly by returning an existing
>>> vector to save having to allocate a new one:
>>>
>>> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>>>
>>> int numedges = edges.size();
>>>
>>> if (numedges < 2) {
>>>
>>> return edges;
>>>
>>> }
>>>
>>> Method pruneEdges however is supposed to return a minimum set of curves
>>> that enclose an area.  A single edge can't contribute any area. I'm pretty
>>> sure that if you change the check to `numedges < 1` that if the remaining
>>> code runs normally it would also come to that conclusion (it would return
>>> an empty vector of curves).  So this "optimization" here is doing the wrong
>>> thing by potentially returning a single edge instead of always returning an
>>> empty curve vector.
>>>
>>> Now, I'm pretty sure we'll never see this case in practice, due to other
>>> checks being done (specifically the `getOrder() > 0` check when adding
>>> edges) and the likely fact that there is always going to be a minimum of 2
>>> curves being passed to `calculate.  Adding an assert or just modifying the
>>> code, and then running all tests may help verify this.  I believe however
>>> that the code needs to be this:
>>>
>>> private Vector<Curve> pruneEdges(Vector<Edge> edges) {
>>>
>>> int numedges = edges.size();
>>>
>>> if (numedges < 2) {
>>>
>>> return numedges == 0 ? (Vector<Curve>)(Vector<?>)edges : new Vector();
>>> // as a single edge can't encompass any area, a single edge also results in
>>> no curves being returned
>>>
>>> }
>>>
>>> The reason why we do need to return a mutable Vector here is because the
>>> classes using the return value of calculate assume that it is writable and
>>> doesn't need copying.  The ugly double cast of edges is relatively
>>> contained -- it is only casted when empty (to avoid creating another vector
>>> instance), and it was created by this class so its under control.  Always
>>> returning `new Vector()` would also work, but it may perform a tiny bit
>>> slower in some cases (probably not measurable IMHO).
>>>
>>> I suspect the entire class is copied from somewhere, as at the time
>>> JavaFX was written using Vector while at the same time trying to do these
>>> kinds of optimizations is odd to say the least.
>>>
>>> --John
>>>
>>>
>>> On 30/11/2024 00:12, Nir Lisker wrote:
>>>
>>> I came across a potential mistake in the
>>> class com.sun.javafx.geom.AreaOp. It uses raw Vector types and while trying
>>> to add generic parameters there for type safety, I got some conflicts.
>>>
>>> In the method AreaOp::calculate, the arguments should be Vector<Curve>
>>> and the return type should also be Vector<Curve>, but it returns a Vector
>>> called 'edges'. 'edges' is passed to the 'addEdges' method that should
>>> take Vector<Edge> and Vector<Curve>. This means that 'edges' is a
>>> Vector<Edge> and not Vector<Curve>. Already a conflict.
>>> Then it is passed to 'pruneEdges', which, if it takes and returns
>>> Vector<Edge>, runs into a conflict with the return type: 'Vector ret' has
>>> Curve added to it. If I try to return Vector<Curve> instead, then in the
>>> 'numedges < 2' check the input Vector can't be returned unless it's also
>>> Vector<Curve>, which again causes a conflict in 'calculate'.
>>>
>>> There are also 'toArray' calls that seem to not do anything, like in
>>> 'resolveLinks' (line 454) and in 'finalizeSubCurves' (429).
>>>
>>> Can anyone who knows this part of the code take a look?
>>>
>>> - Nir
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241130/380085e5/attachment-0001.htm>