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: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 14:09:52 GMT, Lukasz Kostyra 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 17:11:36 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 16:18:17 GMT, Andy Goryachev 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> <_-fkSD8JfZ3Rq5COeCpGldTBps7N3JnKV-5CwHGnlwk=.bac96475-3ab9-4aa8-91dc-b7c3b3f1b935@github.com> Message-ID: On Thu, 31 Oct 2024 23:14:56 GMT, Kevin Rushforth 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 17:50:11 GMT, Kevin Rushforth 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: <1UeYQ3mWvyCh0aVgIjsylTfMrLIm5zCQEhJvqwTU2tY=.7eed9cac-618b-4ceb-b0c3-8198d4710d9d@github.com> On Thu, 31 Oct 2024 18:31:55 GMT, Kevin Rushforth 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 16:22:11 GMT, Kevin Rushforth 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) () -> { > > 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) () -> { > > 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Thu, 31 Oct 2024 15:16:00 GMT, Glavo 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> <75SubdyqHzkpjYyzdkALcUE7v0SRUdFUXgKmNj0gCqs=.3df90d18-3e14-4d45-a52e-b8b6be425972@github.com> Message-ID: On Thu, 31 Oct 2024 23:11:42 GMT, Kevin Rushforth 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: References: Message-ID: On Thu, 31 Oct 2024 22:55:25 GMT, Andy Goryachev 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: References: Message-ID: On Fri, 1 Nov 2024 09:37:19 GMT, Lukasz Kostyra 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: References: <-Ou7qGSxQbWYEhvG6RsHyT5_4l025v7WfUPppQnYAmk=.576697e0-9548-4aea-ad6a-79a25b9e90d1@github.com> Message-ID: On Fri, 1 Nov 2024 07:21:34 GMT, Laurent Bourg?s 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: On Thu, 31 Oct 2024 22:51:24 GMT, Andy Goryachev 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) () -> 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) () -> 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: References: Message-ID: On Thu, 31 Oct 2024 18:16:51 GMT, Michael Strau? 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: References: Message-ID: On Thu, 31 Oct 2024 17:56:07 GMT, Andy Goryachev 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: References: Message-ID: On Thu, 31 Oct 2024 20:52:50 GMT, Michael Strau? 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: References: Message-ID: <_21wU163cKNnQ4EHZm0XWYV11WrkLgLlcicmTSIXPNk=.3cbd52ea-6abb-48f5-a521-a61fbad1d259@github.com> On Fri, 1 Nov 2024 09:37:19 GMT, Lukasz Kostyra 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: References: Message-ID: On Thu, 31 Oct 2024 13:55:45 GMT, Lukasz Kostyra 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 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Fri, 1 Nov 2024 13:26:25 GMT, Kevin Rushforth 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) () -> 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: > 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Fri, 1 Nov 2024 15:01:10 GMT, Andy Goryachev 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: References: Message-ID: On Thu, 31 Oct 2024 15:42:56 GMT, Michael Strau? 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: References: Message-ID: On Wed, 30 Oct 2024 18:32:55 GMT, Michael Strau? 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Fri, 1 Nov 2024 13:51:19 GMT, Kevin Rushforth 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: References: Message-ID: > 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 ------------- 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: References: Message-ID: On Fri, 1 Nov 2024 17:40:02 GMT, Andy Goryachev 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: *

Usage Considerations

> 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: *
  • 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: References: <2w75n5akpAwuxEXHyW4TuhkaOKmpqsh6tYMFcirZ88c=.1bff67c5-4e7d-468b-a0ce-1cc7b9d86e9e@github.com> Message-ID: On Tue, 29 Oct 2024 19:38:01 GMT, Andy Goryachev 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 { >> >> 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: <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: 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: References: Message-ID: On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Fri, 1 Nov 2024 17:03:16 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 1 Nov 2024 18:49:03 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 1 Nov 2024 20:58:54 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 1 Nov 2024 19:50:24 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 1 Nov 2024 18:42:45 GMT, Kevin Rushforth 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: References: Message-ID: > 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: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> Message-ID: 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: References: Message-ID: > 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: References: Message-ID: > 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 - 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: References: Message-ID: > 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: References: Message-ID: > 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: > 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: References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.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: References: Message-ID: On Wed, 30 Oct 2024 18:21:27 GMT, Andy Goryachev 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: References: Message-ID: On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? 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: References: Message-ID: On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? 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 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: References: Message-ID: On Fri, 1 Nov 2024 17:45:55 GMT, Andy Goryachev 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: <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com> Message-ID: On Wed, 30 Oct 2024 18:16:26 GMT, Andy Goryachev 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: References: Message-ID: On Mon, 28 Oct 2024 15:01:47 GMT, Andy Goryachev 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 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: References: Message-ID: On Mon, 28 Oct 2024 14:59:12 GMT, Andy Goryachev 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 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: References: Message-ID: On Thu, 31 Oct 2024 22:55:25 GMT, Andy Goryachev 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 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: 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: References: Message-ID: <70LIeGfKAFR4BM2aEiHcKa1hQCWjuinbr5Tde5zrXI0=.9645ec62-d3a6-4fcc-be74-c2af92f5e675@github.com> On Mon, 4 Nov 2024 17:42:01 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? 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: References: Message-ID: On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? 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: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.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: References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.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: References: Message-ID: On Fri, 1 Nov 2024 23:38:52 GMT, Michael Strau? 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: *
  • {@link Region} ? {@code window-button}, {@code maximize-button} > 73: *
  • {@link Region} ? {@code window-button}, {@code close-button} > 74: * 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: * > 78: * 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: * > 103: * > 104: * 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> 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: *

    > 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: *

    > 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: References: Message-ID: On Mon, 4 Nov 2024 23:54:52 GMT, Andy Goryachev 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: *

    >> 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: References: Message-ID: > 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: References: Message-ID: On Mon, 4 Nov 2024 20:13:23 GMT, Andy Goryachev 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: References: Message-ID: On Mon, 4 Nov 2024 20:55:41 GMT, Andy Goryachev 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: *

    CSS properties of {@code window-button-container}
    -fx-button-order<integer>0/1/2
    >> 78: * > > 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: References: Message-ID: On Mon, 4 Nov 2024 22:54:55 GMT, Andy Goryachev 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: * >> 103: * >> 104: * > > 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: References: Message-ID: On Mon, 4 Nov 2024 23:21:22 GMT, Andy Goryachev 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: References: Message-ID: <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com> On Mon, 4 Nov 2024 23:57:40 GMT, Andy Goryachev 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: *

    >>> 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: References: Message-ID: On Mon, 4 Nov 2024 23:56:00 GMT, Andy Goryachev 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: References: Message-ID: > 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: References: Message-ID: On Mon, 4 Nov 2024 23:33:34 GMT, Andy Goryachev 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: References: Message-ID: On Mon, 4 Nov 2024 11:28:35 GMT, Thiago Milczarek Sayao 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: References: Message-ID: On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? 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: References: Message-ID: <5J6FkOVa9BEie7CUhiEqFlH4Bv-i_7fdQZQ0mhg3XHk=.de82e99c-42b3-4fb7-a145-50d0540870d4@github.com> On Tue, 5 Nov 2024 00:00:48 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 5 Nov 2024 00:05:43 GMT, Andy Goryachev 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: *

    >> 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: References: Message-ID: On Tue, 5 Nov 2024 00:09:59 GMT, Andy Goryachev 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: 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: References: Message-ID: <5NSldjtN-bXFCzyQWLFshN2UHgqe2yH2cxXswc2rLqc=.33b99dd0-c5c9-4bb5-aa54-c14c59091f71@github.com> On Tue, 5 Nov 2024 00:13:20 GMT, Andy Goryachev 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: <9Z2UDQd4KhxPdIRINT0uj63EPboQPHtjA1zZYZBHuoQ=.058fc733-e304-4a09-9167-0d9742965dca@github.com> Message-ID: On Wed, 30 Oct 2024 18:16:26 GMT, Andy Goryachev 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Fri, 1 Nov 2024 15:01:10 GMT, Andy Goryachev 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: References: <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com> Message-ID: On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn wrote: > > On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn wrote: > > > > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth > > 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: References: <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com> Message-ID: 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 : > On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn wrote: > > > > On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn > wrote: > > > > > > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth > > > 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: 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: References: Message-ID: On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V 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: References: Message-ID: On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V 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) () -> { > 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: References: Message-ID: On Tue, 5 Nov 2024 14:23:13 GMT, Kevin Rushforth 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: 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: References: 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: <42acc8ca-0c92-4241-bb87-d84bb91d0b1b@oracle.com> Message-ID: Vote: YES On Tue, Nov 5, 2024 at 5:02?PM Kevin Rushforth 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: 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: References: Message-ID: Vote: YES From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, November 5, 2024 at 07:02 To: openjfx-dev , Michael Strau? 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: 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: References: Message-ID: On Tue, 5 Nov 2024 01:06:25 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 78: >> >>> 76: * >>> 77: *

    CSS properties of {@code window-button-container}
    -fx-button-order<integer>0/1/2
    >>> 78: * >> >> 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: References: Message-ID: <28zO6gn08JUaHWS0Pvg04vVBurhE8NXDqYI6VIXSKMM=.1af6c197-653f-462b-9a48-56258f7404b1@github.com> On Tue, 5 Nov 2024 01:11:24 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/WindowControlsOverlay.java line 104: >> >>> 102: * >>> 103: * >>> 104: * >> >> 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: References: Message-ID: On Tue, 5 Nov 2024 15:56:24 GMT, Andy Goryachev 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: References: Message-ID: <-YeVTaL1601H03g_o-FLKu06lUJxMGP0mgptB2v6CUw=.0386d838-e04f-474f-9500-a22d54d899dc@github.com> On Tue, 5 Nov 2024 01:13:39 GMT, Michael Strau? 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: <_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? 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: <-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 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: <28zO6gn08JUaHWS0Pvg04vVBurhE8NXDqYI6VIXSKMM=.1af6c197-653f-462b-9a48-56258f7404b1@github.com> Message-ID: On Tue, 5 Nov 2024 15:59:08 GMT, Andy Goryachev 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. *

    * 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: <_gu4XFH2IUumwWmgS7BeoJ0wEQFGD6R_pH4_wMkCuUE=.ff10b5ed-dba0-4a46-a5dd-5998cf1c05c2@github.com> <5ksteP0TOR1uE0DXvHmgIYus2rZRb2fz_MxKU_XAcD4=.5f0404da-4494-4d65-a468-425c7998e816@github.com> Message-ID: On Tue, 5 Nov 2024 16:09:24 GMT, Andy Goryachev 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: References: Message-ID: On Fri, 1 Nov 2024 23:12:58 GMT, Andy Goryachev 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: References: Message-ID: 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 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 on behalf of Michael > Strau? > *Date: *Tuesday, October 22, 2024 at 16:55 > *To: *openjfx-dev > *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: 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: 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: References: Message-ID: On Mon, 4 Nov 2024 17:42:01 GMT, Kevin Rushforth 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 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: References: Message-ID: On Tue, 5 Nov 2024 16:48:04 GMT, PavelTurk 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: On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth 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: On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 5 Nov 2024 01:40:34 GMT, Michael Strau? 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: References: Message-ID: <3aY-MVVWVOOTnoXtYMxmA2jbARdtimTU0APYGoev1nA=.9533d9f7-5eb9-4d49-9637-f7aa86cb08fa@github.com> On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte 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: 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 `` 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: References: Message-ID: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? 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 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: *

    > 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 `

      `, 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: References: Message-ID: On Tue, 5 Nov 2024 06:00:55 GMT, Michael Strau? 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: *

      >>> 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

        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: References: Message-ID: On Mon, 28 Oct 2024 14:52:06 GMT, Andy Goryachev 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 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 16:34:47 GMT, Andy Goryachev 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: > 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Tue, 5 Nov 2024 06:45:09 GMT, Ambarish Rapte 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: <-_1G4bMs1fAgCS1AJx1t1QTeVYgWpY5ZuwhnVFmBPJw=.d41e7ca7-bc9b-44d8-b0f0-25ee27c845dd@github.com> On Tue, 5 Nov 2024 20:10:36 GMT, Michael Strau? 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: References: Message-ID: On Tue, 5 Nov 2024 01:32:16 GMT, Michael Strau? 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: References: Message-ID: On Tue, 5 Nov 2024 18:20:53 GMT, Thiago Milczarek Sayao 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 16:36:26 GMT, Andy Goryachev 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 20:31:30 GMT, Michael Strau? 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: References: Message-ID: Vote: YES On Tue, Nov 5, 2024 at 4:02?PM 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 16:47:00 GMT, Andy Goryachev 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 19:08:53 GMT, Andy Goryachev 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 20:41:01 GMT, Michael Strau? 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: References: Message-ID: On Tue, 5 Nov 2024 16:48:04 GMT, PavelTurk 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 21:02:28 GMT, Andy Goryachev 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 21:17:07 GMT, Michael Strau? 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: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> Message-ID: 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 on behalf of Kevin Rushforth Date: Friday, November 1, 2024 at 15:18 To: openjfx-dev 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: 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: References: Message-ID: > 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: References: Message-ID: > 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 16:37:48 GMT, Andy Goryachev 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@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 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Tue, 5 Nov 2024 20:13:58 GMT, Andy Goryachev 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com> Message-ID: On Tue, 5 Nov 2024 21:48:04 GMT, Michael Strau? 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: References: Message-ID: On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com> Message-ID: On Tue, 5 Nov 2024 22:01:10 GMT, Andy Goryachev 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: References: Message-ID: Vote: YES On Tue, Nov 5, 2024 at 9:43?PM Johan Vos wrote: > Vote: YES > > On Tue, Nov 5, 2024 at 4:02?PM 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 >> >> -- -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> <5IZavzvp-OIzH8WY7sh7isG2D1my0RwYT_mzdMp1Nds=.ef82a514-c7e8-405f-8a2c-6beddbe5952d@github.com> Message-ID: On Tue, 5 Nov 2024 22:39:57 GMT, Michael Strau? 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: References: 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: References: Message-ID: On Tue, 5 Nov 2024 21:31:56 GMT, Michael Strau? 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: References: 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: 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: References: Message-ID: On Tue, 5 Nov 2024 23:41:32 GMT, Kevin Rushforth 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 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: References: <9YIofh3yqYuBMCKJu6npy3ATr9UqctwDIZAR2qNMD7k=.9001501d-8f45-4703-8d3d-00d59108c987@github.com> Message-ID: On Tue, 5 Nov 2024 20:13:58 GMT, Andy Goryachev 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: References: Message-ID: > 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: References: Message-ID: On Tue, 5 Nov 2024 18:51:34 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: <1rMQYYNPI9zJ1er4Sb0WDi6fOaeEmT5xI8grfUw9fO4=.09dd9970-c7b4-4aad-ae71-02530d5cae31@github.com> On Tue, 5 Nov 2024 14:39:03 GMT, Kevin Rushforth 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: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> <316c9c47-0450-4424-bd6b-9466232e6a57@oracle.com> Message-ID: 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: References: Message-ID: Vote: YES Regards, Ajit > On 5 Nov 2024, at 8:31?PM, 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 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: References: <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com> Message-ID: 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 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 : >> >> On Mon, Oct 7, 2024 at 5:01?PM Johan Corveleyn wrote: >> > >> > On Tue, Oct 1, 2024 at 10:30?PM Johan Corveleyn wrote: >> > > >> > > On Mon, Sep 30, 2024 at 5:23?PM Kevin Rushforth >> > > 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: References: Message-ID: On Sat, 2 Nov 2024 05:02:20 GMT, Michael Strau? 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: References: Message-ID: On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V 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: References: Message-ID: On Wed, 6 Nov 2024 03:39:09 GMT, Ambarish Rapte 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 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: References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> Message-ID: 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 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 on behalf of Kevin > Rushforth > *Date: *Friday, November 1, 2024 at 15:18 > *To: *openjfx-dev > *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: 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: References: Message-ID: On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V 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: References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> Message-ID: 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 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 > 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 on behalf of Kevin >> Rushforth >> *Date: *Friday, November 1, 2024 at 15:18 >> *To: *openjfx-dev >> *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: 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: References: Message-ID: On Tue, 5 Nov 2024 21:47:54 GMT, Andy Goryachev 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 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: References: Message-ID: On Wed, 6 Nov 2024 03:39:09 GMT, Ambarish Rapte 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: References: Message-ID: On Tue, 5 Nov 2024 23:41:32 GMT, Kevin Rushforth 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 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: References: Message-ID: <_lpYQqb32nGa8tgXp8CzFgD1wEswKjFbxBcWrW9adFA=.636cede4-6457-4a25-bdab-527b7f484d45@github.com> On Tue, 5 Nov 2024 17:42:53 GMT, Ambarish Rapte 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 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: On Wed, 6 Nov 2024 12:15:07 GMT, Kevin Rushforth 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: References: Message-ID: On Wed, 6 Nov 2024 05:13:48 GMT, Jayathirth D V 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: On Thu, 31 Oct 2024 22:51:24 GMT, Andy Goryachev 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 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: References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <966aa54f-7e2d-4fa8-8798-7102549a6c2e@oracle.com> Message-ID: 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 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 > 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 on behalf > of Kevin Rushforth > *Date: *Friday, November 1, 2024 at 15:18 > *To: *openjfx-dev > *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: 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: References: Message-ID: On Tue, 3 Sep 2024 19:09:15 GMT, Andy Goryachev 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: On Fri, 18 Oct 2024 19:20:05 GMT, Andy Goryachev 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: References: <-sr392G05uYl-tZeOWxQV1GRDHj2KgWqMg1jv45irag=.ce8a7983-994a-4a7a-8df6-d13eecd1b47c@github.com> Message-ID: On Thu, 31 Oct 2024 14:58:12 GMT, Andy Goryachev 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: 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: References: Message-ID: > 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 19:03:41 GMT, Andy Goryachev 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: References: Message-ID: On Tue, 5 Nov 2024 20:22:01 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 6 Nov 2024 18:41:38 GMT, Michael Strau? 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: References: Message-ID: On Wed, 6 Nov 2024 10:32:52 GMT, Jayathirth D V 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: > 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: References: Message-ID: > 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: References: Message-ID: On Wed, 6 Nov 2024 20:49:20 GMT, Andy Goryachev 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: *

        > 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: References: Message-ID: On Wed, 6 Nov 2024 20:49:20 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 6 Nov 2024 18:47:18 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 6 Nov 2024 18:46:38 GMT, Michael Strau? 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: References: Message-ID: > 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 - 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: References: Message-ID: On Wed, 6 Nov 2024 21:26:30 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Wed, 6 Nov 2024 22:09:31 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 6 Nov 2024 10:42:47 GMT, Ambarish Rapte 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: References: Message-ID: On Wed, 6 Nov 2024 11:03:50 GMT, Ambarish Rapte 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: References: Message-ID: On Wed, 6 Nov 2024 11:14:48 GMT, Ambarish Rapte 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: References: Message-ID: 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 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 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: References: Message-ID: On Wed, 6 Nov 2024 22:09:31 GMT, Andy Goryachev 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: References: Message-ID: On Mon, 4 Nov 2024 23:01:03 GMT, Andy Goryachev 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: *

      • {@link Region} ? {@code window-button}, {@code maximize-button} >> 73: *
      • {@link Region} ? {@code window-button}, {@code close-button} >> 74: * > > 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: References: Message-ID: On Mon, 4 Nov 2024 20:33:42 GMT, Andy Goryachev 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> 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: References: Message-ID: On Tue, 5 Nov 2024 16:19:50 GMT, Andy Goryachev 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
          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: References: Message-ID: <3A4GXvt7j92ous6JfryuKeDxafIF_Y1yGso7RVzzqYk=.dc2c3ff8-43c9-4208-a4d6-c649a60127d8@github.com> On Tue, 5 Nov 2024 16:32:47 GMT, Andy Goryachev 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: References: Message-ID: > 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: References: Message-ID: On Tue, 5 Nov 2024 16:25:08 GMT, Andy Goryachev 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: References: Message-ID: > 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: References: Message-ID: <2_HFYap8k5ZBzW-OQqHripFnpkZuKuF5T3JSfwNOKCk=.50ca5d89-eb7f-4d7d-b66d-b396de62af3d@github.com> On Mon, 4 Nov 2024 23:36:21 GMT, Andy Goryachev 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: <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 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 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: References: Message-ID: > 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: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Tue, 5 Nov 2024 18:54:11 GMT, Andy Goryachev 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: *

          >> 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 `

            `, 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: References: Message-ID: > 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 - 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: > 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: References: Message-ID: > 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: References: Message-ID: On Wed, 6 Nov 2024 15:37:23 GMT, Kevin Rushforth 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: 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 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 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(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=""; engine.loadContent(content); >>> >>> Sent with [Proton Mail](https://proton.me/mail/home) secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V 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: References: Message-ID: On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V 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: References: Message-ID: <6VG-Y6gjgAlOmiO5kcbBwCls8Bdi-1KMaY9ultsn9Ec=.7f26ed0d-a445-4d7b-9165-e653576030c8@github.com> On Tue, 5 Nov 2024 19:37:05 GMT, Kevin Rushforth 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 `` 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: References: Message-ID: > 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 `` 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: References: Message-ID: On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth 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 `` 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: References: 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 > ?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 > 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 on behalf of > Michael Strau? > *Date: *Friday, October 27, 2023 at 19:41 > *To: *openjfx-dev > *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 > 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: 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: 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: References: Message-ID: On Thu, 7 Nov 2024 13:23:24 GMT, Glavo 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: References: 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 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: References: Message-ID: <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com> On Thu, 7 Nov 2024 14:08:09 GMT, John Hendrikx 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: References: Message-ID: On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V 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: References: Message-ID: > 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: References: <6HFhZp-4U57zGhwWtglbPs3D7M9SkPldtzOuegcDv6Y=.a7f808f7-8b18-435c-a1c8-81a622d99800@github.com> Message-ID: On Thu, 7 Nov 2024 04:09:06 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 83: >> >>> 81: *

            >>> 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 `

              `, 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: <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? 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: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: 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 on behalf of John Hendrikx Date: Thursday, November 7, 2024 at 05:35 To: 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 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 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: 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 on behalf of John Hendrikx Date: Thursday, November 7, 2024 at 05:35 To: 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 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 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: References: Message-ID: On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V 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: References: Message-ID: On Tue, 5 Nov 2024 13:40:55 GMT, Kevin Rushforth 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: References: Message-ID: On Thu, 7 Nov 2024 15:52:04 GMT, Andy Goryachev 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: References: Message-ID: > 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: References: Message-ID: On Thu, 7 Nov 2024 18:20:36 GMT, Michael Strau? 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: References: Message-ID: On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev 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: References: Message-ID: <3nM271bC-xQxs-5PdsQ4lup6DO9p_gk1t8e22ydPUQo=.810a73a5-87bd-43ce-8a5c-b0e4c5c07418@github.com> On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev 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: References: Message-ID: > 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: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: > 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 on behalf of John Hendrikx Date: Thursday, November 7, 2024 at 05:35 To: 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 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 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: 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: References: Message-ID: On Thu, 7 Nov 2024 19:29:38 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Thu, 7 Nov 2024 19:42:32 GMT, Kevin Rushforth 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: References: Message-ID: On Thu, 7 Nov 2024 19:33:11 GMT, Andy Goryachev 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: References: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.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 on behalf of John > Hendrikx > *Date: *Thursday, November 7, 2024 at 05:35 > *To: *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 > ?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 > 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 > on behalf of Michael Strau? > > *Date: *Friday, October 27, 2023 at 19:41 > *To: *openjfx-dev > > *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 > 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: 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: References: 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: References: Message-ID: On Wed, 6 Nov 2024 11:37:07 GMT, Ambarish Rapte 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: References: Message-ID: On Wed, 6 Nov 2024 11:52:35 GMT, Ambarish Rapte 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: References: 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: <9zM9eBSMdUqc2v5wXEVirjAedQOTicriQIbzEAI4w0Y=.2b2578a9-bf5a-4e57-8069-ac12162aca15@github.com> Message-ID: On Thu, 7 Nov 2024 22:11:52 GMT, Kevin Rushforth 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: References: 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 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: References: Message-ID: On Thu, 7 Nov 2024 19:41:58 GMT, Andy Goryachev 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: References: Message-ID: On Wed, 6 Nov 2024 11:59:10 GMT, Ambarish Rapte 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 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Wed, 6 Nov 2024 13:43:51 GMT, Ambarish Rapte 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: <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com> Message-ID: On Thu, 7 Nov 2024 14:40:43 GMT, John Hendrikx 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: <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com> Message-ID: On Thu, 7 Nov 2024 20:36:50 GMT, John Hendrikx 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: References: Message-ID: On Thu, 7 Nov 2024 07:15:59 GMT, Jayathirth D V 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: References: <8Kw8VbBjfEOqxKElTFYzAITArsAuSiheZl-lLzMIGo0=.1a898318-757c-43d1-8cfd-47c40ce55f3d@github.com> Message-ID: On Fri, 8 Nov 2024 00:39:34 GMT, Martin Fox 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: References: <1aY7qZ--l2BJMle9AIGns2noMwVtGEnsdUqXSiuljQQ=.43f7d0e7-f92c-4080-88ae-93cbf6e43771@github.com> Message-ID: On Fri, 8 Nov 2024 00:35:10 GMT, Martin Fox 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: References: Message-ID: On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth 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 `` 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: References: Message-ID: On Thu, 7 Nov 2024 14:13:16 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 5 Nov 2024 06:12:20 GMT, Jayathirth D V 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 Committer: Lukasz Kostyra 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: References: Message-ID: On Wed, 11 Dec 2019 12:26:27 GMT, Jeanette Winzenburg 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: Vote: YES On Fri, Nov 8, 2024 at 3:48?PM Kevin Rushforth 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: 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: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> Message-ID: On Tue, 12 Sep 2023 23:28:37 GMT, John Hendrikx 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` or `Set` 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: 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: Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Friday, November 8, 2024 at 05:47 To: openjfx-dev , Jayathirth Rao Daarapuram Venkatesh Murthy 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: 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: References: Message-ID: On Fri, 8 Nov 2024 12:48:45 GMT, John Hendrikx 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: ? ?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: 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: References: Message-ID: On Fri, 8 Nov 2024 15:31:04 GMT, Andy Goryachev 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 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 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: References: Message-ID: <4EkzA7YFSMo9HJaQUW0LHGL_bLeI1mfgV73NESjD3xM=.67ffe374-4484-466e-9cef-7c5cac22b76e@github.com> On Thu, 7 Nov 2024 13:17:33 GMT, Kevin Rushforth 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 `` 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: References: Message-ID: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> On Fri, 8 Nov 2024 15:39:57 GMT, Jeanette Winzenburg 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 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 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.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: On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth 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: On Tue, 5 Nov 2024 17:57:19 GMT, Kevin Rushforth 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 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: References: Message-ID: On Tue, 5 Nov 2024 19:37:05 GMT, Kevin Rushforth 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 `` 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 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: References: Message-ID: On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev 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: References: Message-ID: On Thu, 7 Nov 2024 19:29:38 GMT, Kevin Rushforth 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 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: References: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: 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 on behalf of John > Hendrikx > *Date: *Thursday, November 7, 2024 at 05:35 > *To: *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 > ?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 > 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 > on behalf of Michael Strau? > > *Date: *Friday, October 27, 2023 at 19:41 > *To: *openjfx-dev > > *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 > 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: 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: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> Message-ID: On Fri, 8 Nov 2024 16:28:17 GMT, Kevin Rushforth 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 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 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.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: References: Message-ID: On Thu, 7 Nov 2024 19:04:07 GMT, Michael Strau? 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: References: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: 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 on behalf of Tobias Oelgarte Date: Friday, November 8, 2024 at 12:47 To: 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 on behalf of John Hendrikx Date: Thursday, November 7, 2024 at 05:35 To: 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 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 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: References: Message-ID: On Fri, 8 Nov 2024 18:44:22 GMT, Kevin Rushforth 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: References: Message-ID: On Thu, 7 Nov 2024 18:44:23 GMT, Andy Goryachev 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: 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: References: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> Message-ID: On Fri, 8 Nov 2024 20:44:17 GMT, John Hendrikx 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.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: References: Message-ID: On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth 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: References: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> Message-ID: <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com> On Fri, 8 Nov 2024 22:05:15 GMT, Martin Fox 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: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com> Message-ID: On Sat, 9 Nov 2024 00:22:42 GMT, John Hendrikx 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: 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: <13e37580-4e3f-4c81-8eba-0c186806a739@gmail.com> Message-ID: 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 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: References: Message-ID: 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 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: References: Message-ID: > 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: > 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: References: 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 - ... 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: References: <3CNo4fiqmSrSbkQz-d4_6JU7P7ZoHA6cAvLm72LI6b8=.155f35bb-2622-4060-bb11-9b49bd1733cc@github.com> <6VkkAp1KHWJu1VCQEec5Fcy8hpZrhWsJXshHm5POxLc=.c9fc865f-98eb-49a6-8889-558d6af3d5cd@github.com> Message-ID: On Sat, 9 Nov 2024 00:49:22 GMT, Martin Fox 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: 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: void ifUnconsumed(EventHandler 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: References: Message-ID: On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth 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: References: Message-ID: 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: References: 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 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: Vote: YES ~ Ambarish From: openjfx-dev on behalf of Kevin Rushforth Date: Friday, 8 November 2024 at 7:17?PM To: openjfx-dev , Jayathirth Rao Daarapuram Venkatesh Murthy 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: 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: 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: References: Message-ID: > 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: Vote: YES On Fri, Nov 8, 2024 at 2:47?PM Kevin Rushforth 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 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: References: 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: > > void ifUnconsumed(EventHandler 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: References: 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: References: Message-ID: On Mon, 11 Nov 2024 19:34:04 GMT, Martin Fox 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: Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, November 12, 2024 at 08:23 To: openjfx-dev , Lukasz Kostyra 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: 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: References: Message-ID: 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 on behalf of Michael Strau? Date: Friday, November 8, 2024 at 17:52 To: Cc: openjfx-dev 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 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: 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: An HTML attachment was scrubbed... URL: 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: References: <75f8a110-6c86-4eeb-bbdc-9b6925f8f9c5@oracle.com> Message-ID: Vote: YES On Tue, Nov 12, 2024 at 6:24?PM Andy Goryachev wrote: > Vote: YES > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Tuesday, November 12, 2024 at 08:23 > *To: *openjfx-dev , 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: 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: References: Message-ID: 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 on behalf of Michael Strau? Date: Saturday, November 9, 2024 at 23:13 To: openjfx-dev 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: void ifUnconsumed(EventHandler 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: 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: References: Message-ID: <73FL1Cii_myIcXRLHVizv1u_imfVUtdd_jOsfWeyvfc=.9f67e7fe-64e1-4113-9193-635f97f36b2b@github.com> On Sat, 9 Nov 2024 07:45:19 GMT, Michael Strau? 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 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: References: 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 on behalf of > Michael Strau? > *Date: *Friday, November 8, 2024 at 17:52 > *To: * > *Cc: *openjfx-dev > *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 > 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: 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: <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com> Message-ID: (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 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: >> >> void ifUnconsumed(EventHandler 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: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com> Message-ID: 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 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 > on behalf of Michael Strau? > > *Date: *Friday, November 8, 2024 at 17:52 > *To: * > *Cc: *openjfx-dev > *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 > 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: 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: 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: References: <140065d2-cf8d-46d0-82d5-291a8b62fbb1@gmail.com> Message-ID: 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 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: >>> >>> void ifUnconsumed(EventHandler 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: References: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com> Message-ID: 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 > 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 >> on behalf of Michael Strau? >> >> *Date: *Friday, November 8, 2024 at 17:52 >> *To: * >> *Cc: *openjfx-dev >> >> *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 >> 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: 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: References: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com> Message-ID: 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 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: References: <1acbbf11-03b5-414b-a60c-178f31b97daf@oracle.com> Message-ID: 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 on behalf of Nir Lisker Date: Tuesday, November 12, 2024 at 10:47 To: Kevin Rushforth Cc: 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 > 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 on behalf of Michael Strau? Date: Friday, November 8, 2024 at 17:52 To: Cc: openjfx-dev 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 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: 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: References: Message-ID: 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: References: 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: 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: On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl 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: References: Message-ID: On Wed, 6 Nov 2024 17:49:59 GMT, Andy Goryachev 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 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: References: Message-ID: > 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: References: 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: References: <140065d2-cf8d-46d0-82d5-291a8b62fbb1@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 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 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: >>>> >>>> void ifUnconsumed(EventHandler 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: References: Message-ID: On Fri, 1 Nov 2024 16:59:50 GMT, Kevin Rushforth 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: References: Message-ID: On Wed, 13 Nov 2024 04:38:51 GMT, Jayathirth D V 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 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: <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? 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 > - ... 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: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com> Message-ID: On Sat, 9 Nov 2024 07:43:43 GMT, Michael Strau? 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 > - ... 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: References: Message-ID: On Wed, 13 Nov 2024 06:17:18 GMT, Michael Strau? 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: References: 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: <8ab1l9D8v0LiPCSUUXLhd_U1ByX93ANxPXD0iBIMZaU=.38438e6d-2177-43d3-ac6e-bb89122bbb12@github.com> Message-ID: On Wed, 13 Nov 2024 13:33:06 GMT, Kevin Rushforth 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: References: Message-ID: On Fri, 8 Nov 2024 22:06:11 GMT, Andy Goryachev 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: References: Message-ID: On Mon, 11 Nov 2024 08:12:08 GMT, Lukasz Kostyra 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: References: Message-ID: > 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: References: Message-ID: On Tue, 12 Nov 2024 14:45:35 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Wed, 13 Nov 2024 13:58:28 GMT, Kevin Rushforth 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: References: Message-ID: > 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: References: Message-ID: On Wed, 13 Nov 2024 15:53:49 GMT, Kevin Rushforth 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: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com> Message-ID: On Sat, 9 Nov 2024 07:43:43 GMT, Michael Strau? 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 > - ... 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 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: References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com> Message-ID: <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com> On Wed, 13 Nov 2024 18:10:30 GMT, Andy Goryachev 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> cells = row.getChildrenUnmodifiable().stream(). > > minor suggestion: maybe reformat to keep one statement per line > > > row.getChildrenUnmodifiable().stream(). > filter(TableCell.class::isInstance). > map(e -> (TableCell) 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: On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl 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> cells = row.getChildrenUnmodifiable().stream(). minor suggestion: maybe reformat to keep one statement per line row.getChildrenUnmodifiable().stream(). filter(TableCell.class::isInstance). map(e -> (TableCell) 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: References: Message-ID: > 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: <1xkfCYsKhmL4tY61nq22l5sZ-mqaItwctJoSq_FJTLo=.709a52a2-2443-4b62-bc69-c0b4c805148b@github.com> <6Kl9X-DUY32jFTMnaogysceknbzo_AeSNAHq5bBisEg=.8062a614-9766-4f65-beb8-6b1376bb0095@github.com> Message-ID: On Wed, 13 Nov 2024 12:15:20 GMT, John Hendrikx 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 >> - ... 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: References: Message-ID: On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? 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: References: Message-ID: 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 on behalf of Michael Strau? Date: Friday, November 8, 2024 at 17:35 To: openjfx-dev 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: 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: References: Message-ID: On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? 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: On Wed, 13 Nov 2024 18:07:37 GMT, Andy Goryachev 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: > 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> <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com> Message-ID: On Wed, 13 Nov 2024 18:10:49 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 222: >> >>> 220: row.updateIndex(0); >>> 221: >>> 222: List> cells = row.getChildrenUnmodifiable().stream(). >> >> minor suggestion: maybe reformat to keep one statement per line >> >> >> row.getChildrenUnmodifiable().stream(). >> filter(TableCell.class::isInstance). >> map(e -> (TableCell) 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: <84eda7bc-1027-465e-80df-a28d4bf69256@gmail.com> Message-ID: > 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 on behalf of John Hendrikx Date: Tuesday, November 12, 2024 at 12:18 To: 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: 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: References: Message-ID: 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 Date: Monday, October 30, 2023 at 12:53 To: Michael Strau? , openjfx-dev 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 on behalf of Michael Strau? Date: Friday, October 27, 2023 at 19:41 To: openjfx-dev 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 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: 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: References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com> Message-ID: On Wed, 13 Nov 2024 20:02:01 GMT, Marius Hanl 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: References: <6S-4W5Lokt8hqo821Pf4_-1H8nvFm9WII0bzhtPebTw=.026ff144-b699-44d3-b33c-958ae5dbccaa@github.com> <74hF8uGnhNX7U9h307T16Vno5t7W3rJ5oK50c9FOWZA=.a7c93a7f-217a-4370-ab12-9a7584e662d6@github.com> Message-ID: On Wed, 13 Nov 2024 19:58:10 GMT, Marius Hanl 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: References: Message-ID: On Mon, 7 Oct 2024 15:13:17 GMT, Michael Strau? 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? 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: References: Message-ID: > 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: References: Message-ID: On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? 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: References: Message-ID: On Wed, 13 Nov 2024 18:33:27 GMT, Michael Strau? 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: References: Message-ID: On Wed, 13 Nov 2024 22:38:27 GMT, Andy Goryachev 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: References: 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: References: Message-ID: On Fri, 1 Nov 2024 23:39:51 GMT, Michael Strau? 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: 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: References: Message-ID: On Wed, 13 Nov 2024 23:56:55 GMT, Michael Strau? 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: 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: References: Message-ID: On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth 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: References: Message-ID: On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth 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: 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: 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: On Thu, 14 Nov 2024 12:01:29 GMT, Ambarish Rapte 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: References: Message-ID: On Thu, 14 Nov 2024 09:32:33 GMT, Johan Vos 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: 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: References: Message-ID: On Thu, 14 Nov 2024 12:22:15 GMT, Kevin Rushforth 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: References: Message-ID: <4PSf_QEHKXBB6xajkwhNl2vnfpWz9AyA9T1NMgnq8Kw=.1cddd19c-82e6-4e05-ac83-72d2818dc5e0@github.com> On Thu, 14 Nov 2024 00:34:26 GMT, Kevin Rushforth 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: On Thu, 14 Nov 2024 12:01:29 GMT, Ambarish Rapte 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: References: <1_zIuG43Ssu7tHwV3cTNrzAc1Y3sgHk4B03n0L-aU6M=.97c6768b-ff39-4c20-9a1c-59e65684389d@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 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: References: Message-ID: On Wed, 13 Nov 2024 22:06:12 GMT, Kevin Rushforth 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: References: Message-ID: <-NPIvmoRXDjuIdvGvdo5DfHuHLQSlyntKHg3DyZouHI=.51ecd519-893b-4e6f-a786-4084b40cdaf2@github.com> On Wed, 13 Nov 2024 23:56:55 GMT, Michael Strau? 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? 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: References: Message-ID: On Sat, 9 Nov 2024 07:45:19 GMT, Michael Strau? 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Thu, 14 Nov 2024 15:43:53 GMT, Martin Fox 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: References: Message-ID: <6t47XGW0RGHueKNLGMhmSgNc76WtNRNWKBn33pszME4=.e0e29bbd-6241-492a-b66e-d6767ef2f267@github.com> On Thu, 14 Nov 2024 15:53:50 GMT, Martin Fox 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: References: Message-ID: On Thu, 14 Nov 2024 17:51:54 GMT, Michael Strau? 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: On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl 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 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: References: Message-ID: <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com> On Thu, 14 Nov 2024 18:19:14 GMT, Andy Goryachev 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: <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com> Message-ID: On Thu, 14 Nov 2024 18:59:09 GMT, Michael Strau? 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: References: <8mTcDiXppfbHuO9Q-iJz6Yw-jrcvpXrzjjifZS_h7Ng=.8331102f-3905-4a1b-aa95-838e5981599a@github.com> Message-ID: On Thu, 14 Nov 2024 19:03:50 GMT, Andy Goryachev 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: References: Message-ID: 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: 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: References: Message-ID: On Fri, 8 Nov 2024 21:46:38 GMT, Kevin Rushforth 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 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: References: Message-ID: > 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**). Als
    CSS properties of {@code window-button-container}
    -fx-button-order<integer>0/1/2