From duke at openjdk.org Wed May 1 04:46:29 2024 From: duke at openjdk.org (Oliver Kopp) Date: Wed, 1 May 2024 04:46:29 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v25] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.org/browse/JDK-8330462. > > If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: Adress review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1442/files - new: https://git.openjdk.org/jfx/pull/1442/files/92155148..45a56c6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=24 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=23-24 Stats: 19 lines in 2 files changed: 1 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1442.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442 PR: https://git.openjdk.org/jfx/pull/1442 From duke at openjdk.org Wed May 1 04:51:01 2024 From: duke at openjdk.org (Oliver Kopp) Date: Wed, 1 May 2024 04:51:01 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v24] In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 14:10:42 GMT, Ambarish Rapte wrote: > In addition to the [evaluation](https://bugs.openjdk.org/browse/JDK-8330462?focusedId=14666181&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14666181) added by `@jperedadnr` to [JDK-8330462](https://bugs.openjdk.org/browse/JDK-8330462) Thank you for the long investigation! I incorporated your updates, renamed the end variable to `endIndex`, and tried to add some more JavaDoc mirroring your input. - Reads good for me now :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2087973053 From lkostyra at openjdk.org Wed May 1 06:36:58 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 1 May 2024 06:36:58 GMT Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v4] In-Reply-To: References: Message-ID: On Tue, 30 Apr 2024 18:51:24 GMT, Martin Fox wrote: >> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event. >> >> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Update to match coding standards LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2033111227 From kcr at openjdk.org Wed May 1 12:23:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 May 2024 12:23:01 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v25] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 04:46:29 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Adress review comments The latest version of the fix and the test looks good to me, although I'll let @arapte and @andy-goryachev-oracle formally review it. ------------- PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2033525518 From kcr at openjdk.org Wed May 1 12:23:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 May 2024 12:23:01 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v24] In-Reply-To: References: Message-ID: <96hqxulNjBI6lDs89sUONrkyhV0vtJ6bjuvfnmQizqE=.5af01fc4-a28e-4cf8-b47b-020b7931ca40@github.com> On Mon, 29 Apr 2024 17:53:50 GMT, Ambarish Rapte wrote: >> I applied the software engineering principle to leave the code cleaner than seen. (Martin Fowler et all) >> >> Should I revert this? > > Sorry for not being clear. I just wanted to point out that it is not required for the issue fix. > Please don't revert. This looks better. This is the sort of tangentially-related change that should usually be avoided. In this specific case, `clamp(min, val, max)` will produce the same results as `max(start, min(val, end))`, but it isn't guaranteed to do so for malformed input where `max < min`. Given that `text.length()` always returns a non-negative number, the first call to `clamp` is identical to the existing code. And since the resulting` start` value is guaranteed to be `<= length`, the second call to `clamp` is also equivalent. But... reviewers shouldn't have to spend time verifying this to ensure no regression. Since Ambarish is the primary reviewer of this, and he is OK with this change (and I already did spend the time to verify that it is equivalent), then I don't insist that you revert it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1586241421 From mfox at openjdk.org Wed May 1 14:07:57 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 1 May 2024 14:07:57 GMT Subject: Integrated: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 22:35:49 GMT, Martin Fox wrote: > At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event. > > At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations. This pull request has now been integrated. Changeset: aa9907a5 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/aa9907a58e24bc997a6762d62542a9cc6234dbe3 Stats: 253 lines in 6 files changed: 245 ins; 1 del; 7 mod 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1371 From tsayao at openjdk.org Wed May 1 21:41:16 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 1 May 2024 21:41:16 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v9] In-Reply-To: References: Message-ID: > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: rollback file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1381/files - new: https://git.openjdk.org/jfx/pull/1381/files/619ae9c4..8618dd77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381 From tsayao at openjdk.org Wed May 1 21:48:12 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 1 May 2024 21:48:12 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v10] In-Reply-To: References: Message-ID: > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into egl - Prefer EGL over GLX - Merge branch 'master' into egl - Merge branch 'master' into egl # Conflicts: # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c - Use EGL instead of GLX ------------- Changes: https://git.openjdk.org/jfx/pull/1381/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=09 Stats: 2441 lines in 36 files changed: 1857 ins; 489 del; 95 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381 From duke at openjdk.org Thu May 2 06:13:01 2024 From: duke at openjdk.org (Undecium) Date: Thu, 2 May 2024 06:13:01 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v7] In-Reply-To: References: Message-ID: <1vbM9S2nM1-3GWIFetz0ZmtV3dNK1BKjoZSYdaXeca8=.8cbfd1d2-03ee-4417-8d2e-4698a9cefc63@github.com> On Thu, 7 Mar 2024 22:32:13 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ >> See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [x] Adjust copyright >> - [x] Write Systemtest >> - [x] Document the new behaviour - in general, there should be more information what to expect > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Integrate changes as outline by beldenfox Please don't close this pull request. I really need this fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-2089657232 From mstrauss at openjdk.org Thu May 2 08:40:28 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 May 2024 08:40:28 GMT Subject: RFR: 8311895: CSS Transitions [v16] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: - Merge branch 'master' into feature/css-transitions - update 'since' tags - Fix javadoc error - Change javadoc comment - Merge branch 'master' into feature/css-transitions - Discard redundant transitions in StyleableProperty impls - Changes per review - Merge branch 'master' into feature/css-transitions - Merge branch 'master' into feature/css-transitions - Add TransitionMediator - ... and 43 more: https://git.openjdk.org/jfx/compare/aa9907a5...6614abb9 ------------- Changes: https://git.openjdk.org/jfx/pull/870/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=15 Stats: 4673 lines in 43 files changed: 4630 ins; 4 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From duke at openjdk.org Thu May 2 09:30:02 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 09:30:02 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases [v2] In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com> References: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com> Message-ID: <5wAU-RT08Molw-lvJhpMFRTpd8GL4EtzwSab7kHG8s4=.bb10c15c-c8ec-421f-b7e2-9ed7456cf7c5@github.com> On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac wrote: >> This PR should fix the issue and cover all relevant cases with new tests. >> >> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic thanks for creating the issue, I can create the PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2090006139 From arapte at openjdk.org Thu May 2 10:06:02 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 May 2024 10:06:02 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v25] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 04:46:29 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Adress review comments The fix looks good, I have few comments about the test. 1. The test does not compile without fix, hence it won't fail without fix as we are only testing the newly added helper method. 2. It is not required to change the error stream, as the test does/need not inspect the error output. 3. The test method and parameter source method names can be changed a little. 4. We should use the Util class for standard setup like initializing JavaFX/ shutting it down. I tried above changes to test locally, attaching the file for ease. [WinTextRangeProviderTest.zip](https://github.com/openjdk/jfx/files/15186626/WinTextRangeProviderTest.zip) ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2035329983 From duke at openjdk.org Thu May 2 10:06:23 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 10:06:23 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v2] In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: > This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. drmarmac has updated the pull request incrementally with one additional commit since the last revision: JavaDoc updates ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1432/files - new: https://git.openjdk.org/jfx/pull/1432/files/df510c22..b86cdfe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1432&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1432&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1432.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1432/head:pull/1432 PR: https://git.openjdk.org/jfx/pull/1432 From duke at openjdk.org Thu May 2 10:06:24 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 10:06:24 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: On Sun, 24 Mar 2024 15:11:29 GMT, drmarmac wrote: > This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. I've updated the PR with Kevin's suggestions. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1432#issuecomment-2090076000 From duke at openjdk.org Thu May 2 10:06:24 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 10:06:24 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v2] In-Reply-To: References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: On Mon, 29 Apr 2024 22:48:28 GMT, Kevin Rushforth wrote: >> drmarmac has updated the pull request incrementally with one additional commit since the last revision: >> >> JavaDoc updates > > modules/javafx.base/src/main/java/javafx/collections/transformation/TransformationList.java line 134: > >> 132: * @param index the index of an element in this list >> 133: * @return the index of the element's origin in the provided list >> 134: * @throws IndexOutOfBoundsException if the index is out of range (index < 0 || index >= list.getSource().size()) > > There is no`getSource` method in `ObservableList`. That should be `... index >= size())` fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1432#discussion_r1587375665 From kcr at openjdk.org Thu May 2 13:01:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 13:01:06 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v2] In-Reply-To: References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: On Thu, 2 May 2024 10:06:23 GMT, drmarmac wrote: >> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc updates Thanks for updating the docs. I did leave one more suggested change to use `{@code ...}` for code case. Also, can you please merge in the latest upstream master? modules/javafx.base/src/main/java/javafx/collections/transformation/TransformationList.java line 121: > 119: * @param index the index in this list > 120: * @return the index of the element's origin in the source list > 121: * @throws IndexOutOfBoundsException if the index is out of range (index < 0 || index >= size()) In javadoc comments, we prefer using `{@code ... }` rather than the raw HTML tags. This also allows using `<` rather than `<`. Suggested change: ... ({@code index < 0 || index >= size()}) ------------- PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2035586643 PR Review Comment: https://git.openjdk.org/jfx/pull/1432#discussion_r1587540290 From duke at openjdk.org Thu May 2 13:12:09 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 13:12:09 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v3] In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: > This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. drmarmac 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 remote-tracking branch 'refs/remotes/origin/master' into fixes/transformation-list-oob - use `@code` syntax - JavaDoc updates - TransformationList.getSourceIndex/getViewIndex should throw IOOBE - Add failing test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1432/files - new: https://git.openjdk.org/jfx/pull/1432/files/b86cdfe8..e72f21cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1432&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1432&range=01-02 Stats: 18143 lines in 606 files changed: 11428 ins; 4729 del; 1986 mod Patch: https://git.openjdk.org/jfx/pull/1432.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1432/head:pull/1432 PR: https://git.openjdk.org/jfx/pull/1432 From duke at openjdk.org Thu May 2 13:12:09 2024 From: duke at openjdk.org (drmarmac) Date: Thu, 2 May 2024 13:12:09 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v2] In-Reply-To: References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: <7xyuNJsC5tsmVFqkO5DcapE-ZJHGkIYD3t32mUylHZY=.f61f43aa-2cf0-471b-aad1-b9b6d9d46d8e@github.com> On Thu, 2 May 2024 12:18:30 GMT, Kevin Rushforth wrote: >> drmarmac has updated the pull request incrementally with one additional commit since the last revision: >> >> JavaDoc updates > > modules/javafx.base/src/main/java/javafx/collections/transformation/TransformationList.java line 121: > >> 119: * @param index the index in this list >> 120: * @return the index of the element's origin in the source list >> 121: * @throws IndexOutOfBoundsException if the index is out of range (index < 0 || index >= size()) > > In javadoc comments, we prefer using `{@code ... }` rather than the raw HTML tags. This also allows using `<` rather than `<`. > > Suggested change: > > > ... ({@code index < 0 || index >= size()}) ok, looks better! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1432#discussion_r1587609916 From kcr at openjdk.org Thu May 2 13:47:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 13:47:57 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v3] In-Reply-To: <5N1nh4P3Yw-wwbjRoqT_D159d8D-4-WTKGxxAu0gbJU=.46fcd02b-cfb2-4335-a4a1-98d28219d25c@github.com> References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> <5N1nh4P3Yw-wwbjRoqT_D159d8D-4-WTKGxxAu0gbJU=.46fcd02b-cfb2-4335-a4a1-98d28219d25c@github.com> Message-ID: On Tue, 23 Apr 2024 06:55:18 GMT, Lukasz Kostyra wrote: >> drmarmac 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 remote-tracking branch 'refs/remotes/origin/master' into fixes/transformation-list-oob >> - use `@code` syntax >> - JavaDoc updates >> - TransformationList.getSourceIndex/getViewIndex should throw IOOBE >> - Add failing test > > LGTM @lukostyra Can you re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1432#issuecomment-2090541396 From kcr at openjdk.org Thu May 2 13:47:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 13:47:57 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v3] In-Reply-To: References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: On Thu, 2 May 2024 13:12:09 GMT, drmarmac wrote: >> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. > > drmarmac 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 remote-tracking branch 'refs/remotes/origin/master' into fixes/transformation-list-oob > - use `@code` syntax > - JavaDoc updates > - TransformationList.getSourceIndex/getViewIndex should throw IOOBE > - Add failing test Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2035791854 From arapte at openjdk.org Thu May 2 14:13:00 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 May 2024 14:13:00 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - missing ) > - review comments > - Merge branch 'master' into 8092102.truncated > - add exports > - added unit tests > - Merge remote-tracking branch 'origin/master' into 8092102.truncated > - test > - Merge remote-tracking branch 'origin/master' into 8092102.truncated > - Merge branch 'master' into 8092102.truncated > - labeled helper > - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e Looks good. I tested a few scenarios with TableView, Button, Label. It behaved as expected ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2035862805 From angorya at openjdk.org Thu May 2 15:17:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 15:17:59 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases [v2] In-Reply-To: <5wAU-RT08Molw-lvJhpMFRTpd8GL4EtzwSab7kHG8s4=.bb10c15c-c8ec-421f-b7e2-9ed7456cf7c5@github.com> References: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com> <5wAU-RT08Molw-lvJhpMFRTpd8GL4EtzwSab7kHG8s4=.bb10c15c-c8ec-421f-b7e2-9ed7456cf7c5@github.com> Message-ID: <-Hl30e2CFFwZlVwqwItOWxgr0nYihU_VeFJ5OORmqdg=.dca366d5-c9f5-4a77-b9fa-ab6082688fec@github.com> On Thu, 2 May 2024 09:27:41 GMT, drmarmac wrote: > I can create the PR. thank you! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2090784273 From kcr at openjdk.org Thu May 2 18:28:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 18:28:05 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - missing ) > - review comments > - Merge branch 'master' into 8092102.truncated > - add exports > - added unit tests > - Merge remote-tracking branch 'origin/master' into 8092102.truncated > - test > - Merge remote-tracking branch 'origin/master' into 8092102.truncated > - Merge branch 'master' into 8092102.truncated > - labeled helper > - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e The API changes look good. I left a couple comments on the API docs. I also left a couple questions / comments on the fix and test. I haven't tested it yet. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 33: > 31: * Labeled Helper. > 32: */ > 33: public class LabeledHelper { You might consider making `LabeledHelper` a subclass of `ControlHelper`, which is the usual pattern for helper classes of nodes, although it may not matter here (and could be done later if there was a need). modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 62: > 60: * @return true to use the actual content width, false to delegate to the parent > 61: */ > 62: public static boolean isUseActualContentWidth() { If you make the `useActualContentWidth` flag an instance variable of `Labeled` (see my comment in that class), then you would need to add the `Labeled` as an argument to this method (here and in the accessor method). modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 114: > 112: * by itself looks rather weird. > 113: */ > 114: private static boolean useActualContentWidth; Even given your comment about why it's safe to use a global variable, wouldn't it be cleaner to make it an instance variable? I suppose it might be OK to keep it global, but only if you can show that there are no issues with reentrancy. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 848: > 846: /** > 847: * Indicates whether the text has been truncated > 848: * when it cannot fit into the available width. "when" --> "because" modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 850: > 848: * when it cannot fit into the available width. > 849: *

> 850: * When truncated, the {@link #ellipsisStringProperty() ellipsis string} I recommend either using `@linkplain` or changing the text to `ellipsisString`, matching the name of the property. modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 45: > 43: * in their skins to different code paths. > 44: */ > 45: public class LabeledTruncatedTest { It might be worth adding a test for `Button`. modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 93: > 91: firePulse(); > 92: > 93: assertFalse(control.isTextTruncated()); Can you add a test for the case where we are wrapping and the preferred height is exceeded? ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2036421013 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588087048 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588090900 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588033608 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588065486 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588067300 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588112499 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588113855 From kcr at openjdk.org Thu May 2 18:28:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 18:28:05 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 18:07:12 GMT, Kevin Rushforth 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 15 commits: >> >> - missing ) >> - review comments >> - Merge branch 'master' into 8092102.truncated >> - add exports >> - added unit tests >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - test >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - Merge branch 'master' into 8092102.truncated >> - labeled helper >> - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 33: > >> 31: * Labeled Helper. >> 32: */ >> 33: public class LabeledHelper { > > You might consider making `LabeledHelper` a subclass of `ControlHelper`, which is the usual pattern for helper classes of nodes, although it may not matter here (and could be done later if there was a need). Thinking on it further, let's not do this unless / until there is a need (there likely won't be). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588118640 From angorya at openjdk.org Thu May 2 18:37:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 18:37:00 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 17:37:52 GMT, Kevin Rushforth 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 15 commits: >> >> - missing ) >> - review comments >> - Merge branch 'master' into 8092102.truncated >> - add exports >> - added unit tests >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - test >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - Merge branch 'master' into 8092102.truncated >> - labeled helper >> - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e > > modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 114: > >> 112: * by itself looks rather weird. >> 113: */ >> 114: private static boolean useActualContentWidth; > > Even given your comment about why it's safe to use a global variable, wouldn't it be cleaner to make it an instance variable? I suppose it might be OK to keep it global, but only if you can show that there are no issues with reentrancy. re-entrancy should not be an issue: the flag is used in the context of a single method which is always being called from an fx application thread. I do not want to increase the memory footprint by making it an instance variable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588132322 From angorya at openjdk.org Thu May 2 21:10:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 21:10:10 GMT Subject: RFR: 8092102: Labeled: truncated property [v10] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - csr - Merge branch 'master' into 8092102.truncated - missing ) - review comments - Merge branch 'master' into 8092102.truncated - add exports - added unit tests - Merge remote-tracking branch 'origin/master' into 8092102.truncated - test - Merge remote-tracking branch 'origin/master' into 8092102.truncated - ... and 7 more: https://git.openjdk.org/jfx/compare/aa9907a5...062d47ac ------------- Changes: https://git.openjdk.org/jfx/pull/1389/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=09 Stats: 309 lines in 8 files changed: 279 ins; 19 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Thu May 2 22:10:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 22:10:24 GMT Subject: RFR: 8092102: Labeled: truncated property [v11] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: using properties ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/062d47ac..6ea4c698 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=09-10 Stats: 54 lines in 5 files changed: 29 ins; 14 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Thu May 2 22:17:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 22:17:03 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 18:34:04 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 114: >> >>> 112: * by itself looks rather weird. >>> 113: */ >>> 114: private static boolean useActualContentWidth; >> >> Even given your comment about why it's safe to use a global variable, wouldn't it be cleaner to make it an instance variable? I suppose it might be OK to keep it global, but only if you can show that there are no issues with reentrancy. > > re-entrancy should not be an issue: the flag is used in the context of a single method which is always being called from an fx application thread. > > I do not want to increase the memory footprint by making it an instance variable. on second thought, you are right. we cannot guarantee that someone won't stick a TableView as a graphic into another TableView cell. Switched to use an ephemeral entry in `Node.getProperties()`, same as `Properties.DEFER_TO_PARENT_PREF_WIDTH`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588476651 From angorya at openjdk.org Thu May 2 22:17:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 May 2024 22:17:04 GMT Subject: RFR: 8092102: Labeled: truncated property [v9] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 18:21:52 GMT, Kevin Rushforth 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 15 commits: >> >> - missing ) >> - review comments >> - Merge branch 'master' into 8092102.truncated >> - add exports >> - added unit tests >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - test >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - Merge branch 'master' into 8092102.truncated >> - labeled helper >> - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e > > modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 45: > >> 43: * in their skins to different code paths. >> 44: */ >> 45: public class LabeledTruncatedTest { > > It might be worth adding a test for `Button`. test added > modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 93: > >> 91: firePulse(); >> 92: >> 93: assertFalse(control.isTextTruncated()); > > Can you add a test for the case where we are wrapping and the preferred height is exceeded? test added ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588474995 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1588474917 From kcr at openjdk.org Thu May 2 23:04:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 May 2024 23:04:57 GMT Subject: RFR: 8092102: Labeled: truncated property [v11] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 22:10:24 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > using properties The latest code changes look good. I need to do some more testing tomorrow. I have what I think is a simple test program that isn't behaving like I expected. I'll double-check and let you know. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2091883561 From duke at openjdk.org Thu May 2 23:35:12 2024 From: duke at openjdk.org (Oliver Kopp) Date: Thu, 2 May 2024 23:35:12 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.org/browse/JDK-8330462. > > If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: Streamline WinTextRangeProviderTest Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1442/files - new: https://git.openjdk.org/jfx/pull/1442/files/45a56c6f..d03bdd40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=25 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=24-25 Stats: 28 lines in 1 file changed: 1 ins; 19 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1442.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442 PR: https://git.openjdk.org/jfx/pull/1442 From duke at openjdk.org Thu May 2 23:35:12 2024 From: duke at openjdk.org (Oliver Kopp) Date: Thu, 2 May 2024 23:35:12 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v25] In-Reply-To: References: Message-ID: <8-WqOmqsAhh4cySHSkJNbz75O7dkZNCKT_bzw16KUHg=.1364c17a-9553-428e-a871-988353845030@github.com> On Thu, 2 May 2024 10:03:46 GMT, Ambarish Rapte wrote: > 1. The test does not compile without fix, hence it won't fail without fix as we are only testing the newly added helper method. Yes, we could not build on existing a11y test. > 2. It is not required to change the error stream, as the test does/need not inspect the error output. Nice! > 3. The test method and parameter source method names can be changed a little. Note that `@MethodSoruce` can be used without any parameter - then the same name is used. OK, this is not the style of JFX. For JUnit5, the `test` prefix is not necessary any more (and can be removed - see https://docs.openrewrite.org/recipes/java/testing/cleanup/removetestprefix), but I think, because of consistency, it is kept. > 4. We should use the Util class for standard setup like initializing JavaFX/ shutting it down. Nice! > I tried above changes to test locally, attaching the file for ease. [WinTextRangeProviderTest.zip](https://github.com/openjdk/jfx/files/15186626/WinTextRangeProviderTest.zip) Thank you. I committed at d03bdd40a3340bd85397f (with you as author, hope this is in line with the policies?!). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2091906463 From lkostyra at openjdk.org Fri May 3 08:18:01 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 3 May 2024 08:18:01 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values [v3] In-Reply-To: References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: <_tUy8hoOUnKQmH6gYgV79uAFY_xhvBnt3o2YzKKzR60=.add732ce-564a-471b-8ef8-22118e5a9a6a@github.com> On Thu, 2 May 2024 13:12:09 GMT, drmarmac wrote: >> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. > > drmarmac 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 remote-tracking branch 'refs/remotes/origin/master' into fixes/transformation-list-oob > - use `@code` syntax > - JavaDoc updates > - TransformationList.getSourceIndex/getViewIndex should throw IOOBE > - Add failing test LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2037632992 From duke at openjdk.org Fri May 3 08:26:08 2024 From: duke at openjdk.org (drmarmac) Date: Fri, 3 May 2024 08:26:08 GMT Subject: Integrated: 8271865: SortedList::getViewIndex behaves not correctly for some index values In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> Message-ID: On Sun, 24 Mar 2024 15:11:29 GMT, drmarmac wrote: > This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. This pull request has now been integrated. Changeset: 54005125 Author: drmarmac <6900949+drmarmac at users.noreply.github.com> Committer: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/54005125a3f45489d3071eafd7f219ae621ff7c7 Stats: 54 lines in 5 files changed: 38 ins; 2 del; 14 mod 8271865: SortedList::getViewIndex behaves not correctly for some index values Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1432 From fkirmaier at openjdk.org Fri May 3 10:23:27 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 3 May 2024 10:23:27 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: - JDK-8322619: Add test - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1310/files - new: https://git.openjdk.org/jfx/pull/1310/files/5f9f1574..e3163f30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=03-04 Stats: 204 lines in 2 files changed: 190 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From duke at openjdk.org Fri May 3 10:44:00 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 3 May 2024 10:44:00 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: <8uL76ch06rlwD6XRJdQWkcZIGUR0zwTGCtgdTBwrbaM=.d5b55532-adf6-4f0d-baee-40ce343fce4e@github.com> References: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com> <8uL76ch06rlwD6XRJdQWkcZIGUR0zwTGCtgdTBwrbaM=.d5b55532-adf6-4f0d-baee-40ce343fce4e@github.com> Message-ID: On Wed, 13 Mar 2024 09:13:20 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> reverted accidental change in the .idea folder > > *push* > It's still a important bug. > If someone can guide me on how to write tests for this, i would put in the effort. > Maybe we could make snapshot based tests? That should work on all platforms, right? > (Like testing whether a specific RGB value appears) > Has something in this direction been done somewhere? I added a test that shows that the @FlorianKirmaier's fix works. You can start it with: `gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`. To avoid such errors in the future, I would still suggest the refactoring, which I wrote about in my last comment. @kevinrushforth and @arapte please review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2092749767 From kcr at openjdk.org Fri May 3 13:29:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 May 2024 13:29:02 GMT Subject: RFR: 8092102: Labeled: truncated property [v11] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 22:10:24 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > using properties I found at least one case where this fails to detect truncation. There might be others. I will attach a test case that shows the failure. Additionally, I left a comment about the modifications to Region. Since they are only needed for testing, you can instead add getWidth / getHeight to RegionShim, allowing you to revert all changes to Region (and RegionHelper). modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 857: > 855: } > 856: > 857: return (getWidth() < prefWidth(getHeight())); This is not sufficient to detect all cases where truncation can occur. The assumption that pref width is the full width needed to contain the text does not always hold true. For example, if an app explicitly sets the pref width of a button or label, its width will be set to its pref width. If the text does not fit, it will be truncated, but you won't detect it. I'm not sure you can detect truncation just by looking at the various properties on the Labeled control. Would it be possible to set the value of the truncated property at the point where truncation occurs? That would guarantee a correct answer. modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 87: > 85: > 86: private void test(Labeled control) { > 87: RegionHelper.setWidth(control, 1000); This can (and should) be done using a shim method rather than adding a helper method. If you add setWidth / setHeight to RegionShim you don't need to modify Region. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/RegionHelper.java line 115: > 113: } > 114: > 115: public static void setWidth(Node node, double width) { If you instead add this method to RegionShim, you won't need to modify Region at all, and its impact will be limited to the test classes. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 186: > 184: > 185: @Override > 186: public void setWidth(Node node, double width) { If you add the needed methods to RegionShim, you can revert all changes to this file. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2038130006 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589192349 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589195274 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589196444 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589197018 From kcr at openjdk.org Fri May 3 13:31:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 3 May 2024 13:31:58 GMT Subject: RFR: 8092102: Labeled: truncated property [v11] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 22:10:24 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > using properties Here is a test showing the failure to detect truncated text. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.HBox; import javafx.scene.control.Button; import javafx.scene.control.Label; import javafx.stage.Stage; public class TruncatedTest extends Application { private static final String clickMe = "Click me"; private static final String clickMeAgain = "Click me again, please"; @Override public void start(Stage stage) { stage.setTitle("Truncated Button Text (fails)"); var root = new HBox(10); Scene scene = new Scene(root, 600, 450); var button = new Button(clickMe); button.setPrefWidth(100); button.setOnAction(e -> { button.setText(clickMe.equals(button.getText()) ? clickMeAgain : clickMe); //System.err.println("truncated: " + button.isTextTruncated()); }); root.getChildren().add(button); var label = new Label(); label.textProperty().bind(button.textTruncatedProperty().asString()); root.getChildren().add(label); stage.setScene(scene); stage.show(); } public static void main(String[] args) { Application.launch(args); } } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2093024810 From jhendrikx at openjdk.org Fri May 3 14:40:15 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 3 May 2024 14:40:15 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v12] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Fix generic warnings - Fix merge - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Prevent removal of weak listeners during unlock - Use an overridable method to store latest value - Merge the recursive notification loop code Made loop in ListenerList slightly more generic to allow merging the logic in OldValueCachingListenerList and ListenerList; performance impact seems minimal - Small bug fix in OldValueCachingListenerList - Added a test case to detect and avoid this problem - Improve doc - Move listener call code to ListListenerBase - ... and 17 more: https://git.openjdk.org/jfx/compare/54005125...ffa9b299 ------------- Changes: https://git.openjdk.org/jfx/pull/1081/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=11 Stats: 4358 lines in 39 files changed: 4195 ins; 7 del; 156 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Fri May 3 14:51:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 3 May 2024 14:51:04 GMT Subject: RFR: 8331616: ChangeListener is not triggered when the InvalidationListener is removed Message-ID: This PR provides a fix for the linked issue. The issue was that when an invalidation listener is removed, and the `ExpressionHelper` type changes from `Generic` to `SingleChange` that it would copy the current value of the `Generic` instance before it was updated (this is because invalidation listeners trigger before change listeners and the current value would only be updated **after** invalidation listeners notifications were completed). The code now will update the current value before sending out any notifications **if** there are change listeners present to head off this problem. Added a few test cases to verify this. Note: the PR which replaces `ExpressionHelper` does not have this problem: https://github.com/openjdk/jfx/pull/1081 ------------- Commit messages: - Fix problem in ExpressionHelper that could copy the wrong current value Changes: https://git.openjdk.org/jfx/pull/1448/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1448&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331616 Stats: 69 lines in 2 files changed: 66 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1448.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1448/head:pull/1448 PR: https://git.openjdk.org/jfx/pull/1448 From angorya at openjdk.org Fri May 3 15:28:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 May 2024 15:28:27 GMT Subject: RFR: 8092102: Labeled: truncated property [v12] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: shim ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/6ea4c698..219926cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=10-11 Stats: 36 lines in 4 files changed: 9 ins; 21 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Fri May 3 15:56:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 May 2024 15:56:59 GMT Subject: RFR: 8092102: Labeled: truncated property [v11] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 13:19:17 GMT, Kevin Rushforth wrote: > Would it be possible to set the value of the truncated property at the point where truncation occurs? yes, `LabeledSkinBase.updateDisplayedText()` determines whether the text is truncated or not. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589390518 From angorya at openjdk.org Fri May 3 18:15:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 May 2024 18:15:14 GMT Subject: RFR: 8092102: Labeled: truncated property [v13] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. > > > **Alternative** > > None exists as this requires changes to the core (Utils). > > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: using LabeledSkinBase.updateDisplayedText ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/219926cb..7a0dedd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=11-12 Stats: 183 lines in 7 files changed: 75 ins; 62 del; 46 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Fri May 3 21:00:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 May 2024 21:00:26 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. > > > **Alternative** > > None exists as this requires changes to the core (Utils). > > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/7a0dedd4..7d267043 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Fri May 3 22:33:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 May 2024 22:33:03 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 21:00:26 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace Changed the way the new property is being set. Instead of listening for a bunch of existing properties (that's bad), hooked up directly into `LabeledSkinBase.updateDisplayedText()` which does the actual manipulation with the text. In addition, modified the Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest to add ability to see the value of various properties in real time. For example, to verify that the new property is being updated in the context of a table, select TableView page, set Control -> Context Menu -> Show Properties Monitor, select a cell and right click to open the Property Monitor window. Find a `TextFieldTableCell` in the list and observe the value changing when resizing the column: ![Screenshot 2024-05-03 at 15 27 43](https://github.com/openjdk/jfx/assets/107069028/574968eb-71ea-4f01-af7c-7ddd27c9dd19) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2093841963 From kcr at openjdk.org Sat May 4 14:25:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 May 2024 14:25:03 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 21:00:26 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace Yes, this looks like a better approach for the implementation. I did a quick test and it now works as expected. I left a couple comments inline. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 221: > 219: OverrunStyle type, > 220: String ellipsisString, > 221: AtomicBoolean textTruncated I recommend setting `textTruncated` to false as the first statement (alternatively, add a comment that the caller is expected to initialize it to false). modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 436: > 434: OverrunStyle truncationStyle, > 435: String ellipsisString, > 436: AtomicBoolean textTruncated, Similarly, I recommend setting it to false as the first statement. In this case, I see that it will be set to false in the case where it makes it to the return statement at the end of the method without being truncated, but there is one early return where this isn't the case. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 855: > 853: } > 854: > 855: private ReadOnlyBooleanWrapper textTruncated() { Suggestion: rename this method to something like `textTruncatedImpl()` for clarity (as it is, the method, which is a writable property, shares the same name as the read-only property field, which could be confusing). ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2039358463 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589993165 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589993485 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1589994760 From kcr at openjdk.org Sat May 4 14:29:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 May 2024 14:29:02 GMT Subject: RFR: 8331616: ChangeListener is not triggered when the InvalidationListener is removed In-Reply-To: References: Message-ID: On Fri, 3 May 2024 14:45:24 GMT, John Hendrikx wrote: > This PR provides a fix for the linked issue. > > The issue was that when an invalidation listener is removed, and the `ExpressionHelper` type changes from `Generic` to `SingleChange` that it would copy the current value of the `Generic` instance before it was updated (this is because invalidation listeners trigger before change listeners and the current value would only be updated **after** invalidation listeners notifications were completed). > > The code now will update the current value before sending out any notifications **if** there are change listeners present to head off this problem. > > Added a few test cases to verify this. > > Note: the PR which replaces `ExpressionHelper` does not have this problem: https://github.com/openjdk/jfx/pull/1081 The fix looks good, but I'll formally review it early next week. It could use a second reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1448#issuecomment-2094221119 From mfox at openjdk.org Sat May 4 23:00:25 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 4 May 2024 23:00:25 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen Message-ID: This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into eventloopjam - Background information on how Mac Glass handles invokeLater runnables - Unblock invokeLater runnables when entering new loop just after exiting current one Changes: https://git.openjdk.org/jfx/pull/1449/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285893 Stats: 58 lines in 3 files changed: 58 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1449.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/jfx/pull/1449 From mfox at openjdk.org Sat May 4 23:04:00 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 4 May 2024 23:04:00 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v7] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 22:32:13 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ >> See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [x] Adjust copyright >> - [x] Write Systemtest >> - [x] Document the new behaviour - in general, there should be more information what to expect > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Integrate changes as outline by beldenfox I just submitted my proposed fix for this issue as PR #1449. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-2094495851 From duke at openjdk.org Sat May 4 23:05:55 2024 From: duke at openjdk.org (Christopher Schnick) Date: Sat, 4 May 2024 23:05:55 GMT Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao wrote: > Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration. > > It seems i3 replies with decorated sizes, even if window is not decorated. > > Won't hurt other WMs. So I can reproduce this on my system now and could potentially test this PR. How would one go about this, testing a specific PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2094496333 From duke at openjdk.org Mon May 6 08:28:23 2024 From: duke at openjdk.org (drmarmac) Date: Mon, 6 May 2024 08:28:23 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes Message-ID: This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. ------------- Commit messages: - Update SpinnerValueFactory documentation Changes: https://git.openjdk.org/jfx/pull/1450/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1450&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331214 Stats: 21 lines in 1 file changed: 13 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1450.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1450/head:pull/1450 PR: https://git.openjdk.org/jfx/pull/1450 From fkirmaier at openjdk.org Mon May 6 08:49:27 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 6 May 2024 08:49:27 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/29d610fd..6a02f682 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=01-02 Stats: 37 lines in 2 files changed: 10 ins; 13 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From duke at openjdk.org Mon May 6 09:26:03 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 09:26:03 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible I added a new method ``VirtualFlow.getBlockIncrement()``, which returns the amount of pixels by which the position of the VirtualFlow should be adjusted when clicking on the scrollbar track. Now, if only one cell is visible, the ``VirtualScrollBar`` changes the position of the ``VirtualFlow`` simply by calling the VirtualFlow.scrollPixels(double)``. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2095542279 From kcr at openjdk.org Mon May 6 12:40:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 12:40:02 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: <2JiFARSKjWef-oMkHrnkOwfyjoK3gUK9SWkN1VHGp4g=.7c34cfe5-7f6e-4df0-92c8-8ccea1bf868f@github.com> On Sat, 4 May 2024 14:17:16 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 855: > >> 853: } >> 854: >> 855: private ReadOnlyBooleanWrapper textTruncated() { > > ~Suggestion: rename this method to something like `textTruncatedImpl()` for clarity (as it is, the method, which is a writable property, shares the same name as the read-only property field, which could be confusing).~ Never mind. I missed that the types of the field and method are identical, so I withdraw my suggestion. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1590957454 From kcr at openjdk.org Mon May 6 13:57:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 13:57:05 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 21:00:26 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 837: > 835: * When truncated, the {@link #ellipsisStringProperty() ellipsisString} > 836: * gets inserted in the place dictated by the > 837: * {@link #textOverrun} property. I just noticed that this link doesn't work. Looks like you'll need to change it to point to the `textOverrunProperty()` method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1591041626 From duke at openjdk.org Mon May 6 14:18:03 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 14:18:03 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: <_FfwSoVqGHs2qYcNjBZKZ4rTh0ubcwH5FMh9wQfIElc=.a044e4dc-5072-44c7-9df7-00718d2e27e6@github.com> On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8322619: Add test > - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" > > This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. I created an alternative solution for this bug. See PR: https://github.com/openjdk/jfx/pull/1451 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2096126581 From duke at openjdk.org Mon May 6 14:18:25 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 14:18:25 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty Message-ID: This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. This guarantees: 1. that all dirty flags are removed after rendering, and 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` ------------- Commit messages: - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. Changes: https://git.openjdk.org/jfx/pull/1451/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322619 Stats: 284 lines in 11 files changed: 213 ins; 47 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From angorya at openjdk.org Mon May 6 14:53:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 14:53:04 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: References: Message-ID: <8YR9L7QdKY9u4JslZYXtqHht5EeQWQpXox06topPbTE=.ab5a97ed-d2da-43e1-bb6d-36a6c56ea190@github.com> On Sat, 4 May 2024 14:05:19 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 221: > >> 219: OverrunStyle type, >> 220: String ellipsisString, >> 221: AtomicBoolean textTruncated > > I recommend setting `textTruncated` to false as the first statement (alternatively, add a comment that the caller is expected to initialize it to false). setting to false would be incorrect in the case of multi-line text. I can add a comment, though it's not a public API and there was no comment/javadoc before. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1591128736 From kcr at openjdk.org Mon May 6 15:01:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 15:01:00 GMT Subject: RFR: 8092102: Labeled: truncated property [v14] In-Reply-To: <8YR9L7QdKY9u4JslZYXtqHht5EeQWQpXox06topPbTE=.ab5a97ed-d2da-43e1-bb6d-36a6c56ea190@github.com> References: <8YR9L7QdKY9u4JslZYXtqHht5EeQWQpXox06topPbTE=.ab5a97ed-d2da-43e1-bb6d-36a6c56ea190@github.com> Message-ID: On Mon, 6 May 2024 14:50:00 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 221: >> >>> 219: OverrunStyle type, >>> 220: String ellipsisString, >>> 221: AtomicBoolean textTruncated >> >> I recommend setting `textTruncated` to false as the first statement (alternatively, add a comment that the caller is expected to initialize it to false). > > setting to false would be incorrect in the case of multi-line text. > > I can add a comment, though it's not a public API and there was no comment/javadoc before. Yes, I see. In that case, it's up to you whether to add a simple comment that this should be initialized by the caller (but maybe it doesn't need to be mentioned?) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1591138400 From angorya at openjdk.org Mon May 6 15:23:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 15:23:20 GMT Subject: RFR: 8092102: Labeled: truncated property [v15] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. > > > **Alternative** > > None exists as this requires changes to the core (Utils). > > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/7d267043..cce514ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=13-14 Stats: 34 lines in 2 files changed: 33 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From kcr at openjdk.org Mon May 6 15:28:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 15:28:59 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: <0rqZyZNf7jrtQWvzyfHWtv53fWk5NLzHoPSPB4q4V7c=.3c8b8237-af22-44e7-92cf-aa16675f9c2a@github.com> On Mon, 6 May 2024 15:23:20 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > comments Looks good. You'll need to change the PR title to match the updated JBS title. Also, you can finalize the CSR. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2041049872 From angorya at openjdk.org Mon May 6 15:31:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 15:31:59 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: <0rqZyZNf7jrtQWvzyfHWtv53fWk5NLzHoPSPB4q4V7c=.3c8b8237-af22-44e7-92cf-aa16675f9c2a@github.com> References: <0rqZyZNf7jrtQWvzyfHWtv53fWk5NLzHoPSPB4q4V7c=.3c8b8237-af22-44e7-92cf-aa16675f9c2a@github.com> Message-ID: On Mon, 6 May 2024 15:26:18 GMT, Kevin Rushforth wrote: > Looks good. You'll need to change the PR title to match the updated JBS title. > Also, you can finalize the CSR. Thank you for your help, Kevin! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2096304606 From kcr at openjdk.org Mon May 6 15:42:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 15:42:58 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: References: Message-ID: On Mon, 6 May 2024 08:24:52 GMT, drmarmac wrote: > This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. Looks like a good start. I left a few minor suggestions. @andy-goryachev-oracle Do you also want to take a look? modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 118: > 116: * @param steps The number of decrements that should be performed on the value. > 117: * If the number is negative, the call is equivalent to calling > 118: * {@link #increment(int)} with the absolute number of steps. Suggestion: ... with the absolute value of {@code steps}. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 129: > 127: * @param steps The number of increments that should be performed on the value. > 128: * If the number is negative, the call is equivalent to calling > 129: * {@link #decrement(int)} with the absolute number of steps. Suggestion: ... with the absolute value of {@code steps}. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 419: > 417: * If {@link #wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from > 418: * the minimum value to the maximum value (and vice versa). As a consequence of that, the number > 419: * of steps required to wrap around to the same value is N+1, where N is the number of steps between I recommend code case for `N` and `N+1`. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 420: > 418: * the minimum value to the maximum value (and vice versa). As a consequence of that, the number > 419: * of steps required to wrap around to the same value is N+1, where N is the number of steps between > 420: * {@link #min} (inclusive) and {@link #max} (inclusive). Suggestion: It might be helpful to show the equation: val = (val + delta) % (max - min + 1) modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 621: > 619: * If {@link #wrapAround} is {@code true}, the {@code DoubleSpinnerValueFactory} will step through > 620: * from the maximum value to the minimum value seamlessly; that is, any step up from the maximum value > 621: * is equal to the same step up from the minimum value (and vice versa). Suggestion: It might be helpful to show the equation: val = (val + delta) % (max - min) ------------- PR Review: https://git.openjdk.org/jfx/pull/1450#pullrequestreview-2041073507 PR Comment: https://git.openjdk.org/jfx/pull/1450#issuecomment-2096331641 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591187179 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591187802 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591189203 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591190823 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591191777 From kcr at openjdk.org Mon May 6 15:45:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 15:45:57 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: <2pFl9NxuHxYulxLN41XbHccRZ_0mWeWsUmPgHZtgISQ=.68470865-043c-460c-9642-e30353c0098d@github.com> On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. As with the earlier PR, this will need a lot of testing and careful review. @Maran23 I'd be interested in your thoughts on this approach. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2096342944 From kcr at openjdk.org Mon May 6 15:54:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 15:54:00 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` Reviewers: @lukostyra @arapte This is a more intrusive fix than #1310 so we would only want to go this route if we can show that it is a correct fix, introduces no regressions (in either correctness or performance), and makes it easier to maintain in the future. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2096370830 From kcr at openjdk.org Mon May 6 16:03:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 16:03:59 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v9] In-Reply-To: References: Message-ID: On Mon, 15 Apr 2024 09:57:10 GMT, Karthik P K 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 15 commits: >> >> - missing ) >> - review comments >> - Merge branch 'master' into 8092102.truncated >> - add exports >> - added unit tests >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - test >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - Merge branch 'master' into 8092102.truncated >> - labeled helper >> - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e > > LGTM @karthikpandelu @arapte Can you re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2096392818 From kcr at openjdk.org Mon May 6 16:15:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 16:15:58 GMT Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: On Sat, 4 May 2024 23:03:25 GMT, Christopher Schnick wrote: > So I can reproduce this on my system now and could potentially test this PR. How would one go about this, testing a specific PR? You will need to checkout the PR branch and build JavaFX from source. See the "Using git" instructions added by Skara in the "Reviewing" section of this PR's Description for how to fetch and checkout this PR branch. See the [build instructions Wiki page](https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX) for instructions on building JavaFX. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2096416824 From kcr at openjdk.org Mon May 6 16:30:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 16:30:03 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. This looks like a safe, targeted fix for the problem. It will need to be tested on all platforms with a full run of all system tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2096441265 From angorya at openjdk.org Mon May 6 16:31:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 16:31:56 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: References: Message-ID: On Mon, 6 May 2024 08:24:52 GMT, drmarmac wrote: > This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: > 415: * integer values. > 416: *

> 417: * If {@link #wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from The link for wrapAround does not resolve in Eclipse. I'd suggest to change it to * If {@link SpinnerValueFactory#wrapAround wrapAround} Same comment applies to the min and max in line 420. modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 619: > 617: * double values. > 618: *

> 619: * If {@link #wrapAround} is {@code true}, the {@code DoubleSpinnerValueFactory} will step through wrapAround link does not resolve in Eclipse, see my earlier comment ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591260910 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591264246 From angorya at openjdk.org Mon May 6 16:31:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 16:31:57 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: References: Message-ID: On Mon, 6 May 2024 15:39:02 GMT, Kevin Rushforth wrote: >> This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. > > modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 420: > >> 418: * the minimum value to the maximum value (and vice versa). As a consequence of that, the number >> 419: * of steps required to wrap around to the same value is N+1, where N is the number of steps between >> 420: * {@link #min} (inclusive) and {@link #max} (inclusive). > > Suggestion: It might be helpful to show the equation: > > > val = (val + delta) % (max - min + 1) a good idea ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591262735 From angorya at openjdk.org Mon May 6 16:40:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 16:40:59 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: <2LCaZdFQ7hhJYtocXGjHaXDPINMHvAXcY0eeHCU2TUE=.f1ae9292-1b98-420e-a677-31722e3fb20b@github.com> On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1804: > 1802: > 1803: /** > 1804: * The amount of pixels by which to adjust the position when the the scroll bar track is clicked. should it be the height of the viewport, so to speak? modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1810: > 1808: public double getBlockIncrement() { > 1809: // For reasons of backward compatibility, we use the cell length of the empty cell (cell index -1) > 1810: return getCellLength(-1); How would that work when cell heights are different for each cell? What if the cell height is much larger than the viewport height (as in, 10 times larger?) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1591273143 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1591274020 From duke at openjdk.org Mon May 6 16:56:59 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 16:56:59 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: <2LCaZdFQ7hhJYtocXGjHaXDPINMHvAXcY0eeHCU2TUE=.f1ae9292-1b98-420e-a677-31722e3fb20b@github.com> References: <2LCaZdFQ7hhJYtocXGjHaXDPINMHvAXcY0eeHCU2TUE=.f1ae9292-1b98-420e-a677-31722e3fb20b@github.com> Message-ID: On Mon, 6 May 2024 16:34:22 GMT, Andy Goryachev wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1804: > >> 1802: >> 1803: /** >> 1804: * The amount of pixels by which to adjust the position when the the scroll bar track is clicked. > > should it be the height of the viewport, so to speak? Yes, that would also be my favorite choice for the click on the scrollbar track as well as for the PageUp/PageDown. But for reasons of backwards compatibility, I didn't want to change it here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1591295131 From duke at openjdk.org Mon May 6 17:23:59 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 17:23:59 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: <2LCaZdFQ7hhJYtocXGjHaXDPINMHvAXcY0eeHCU2TUE=.f1ae9292-1b98-420e-a677-31722e3fb20b@github.com> References: <2LCaZdFQ7hhJYtocXGjHaXDPINMHvAXcY0eeHCU2TUE=.f1ae9292-1b98-420e-a677-31722e3fb20b@github.com> Message-ID: <3D9G8qsXg7Jk4fsSgzr8fOsB8Q2fZvAJtB78Tad4b5U=.e5a0c904-0140-4d84-8424-1670289d6ff3@github.com> On Mon, 6 May 2024 16:35:14 GMT, Andy Goryachev wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1810: > >> 1808: public double getBlockIncrement() { >> 1809: // For reasons of backward compatibility, we use the cell length of the empty cell (cell index -1) >> 1810: return getCellLength(-1); > > How would that work when cell heights are different for each cell? > > What if the cell height is much larger than the viewport height (as in, 10 times larger?) I don't like that either, but as I said I didn't want to change it because of backwards compatibility. ---- I would like to make it configurable or even make the complete scrolling behavior interchangeable. Because, the actual scrolling behavior is still not consistent. If multiple cells are visible, the cells are currently aligned (when clicking on the scrollbar) so that they are either exactly at the top or exactly at the bottom. If only one cell is visible, the scrolling behavior changes to the applying of pixel delta. For example, if you have two large cells and a small ViewPort so that only one cell is visible. 1) If you click on the thumb below the scroll bar, the ListView is scrolled by a pixel delta so that two cells can become visible. 2) If you click below scroll thumb again, the ListView scrolls so that the second cell appears at the top. 3) If you click above the scroll thumb, the ListView scrolls by pixel delta, as the second cell is also larger than the viewport. Now the ListView is in a different state than before the click (2). These two behaviors are each useful for their own situation and should not be mixed. 1) Align the cell at the top or bottom if you have cells of the same size that are smaller than the viewport. 2) Scroll by pixel delta if you have cells of different sizes or if the cells are larger than the viewport. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1591327052 From angorya at openjdk.org Mon May 6 17:41:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 17:41:00 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: <2HGSX4oPup43ZmZZ-MO_Ec4clDowYGm2qoq91Yl5QsU=.10675523-245d-4cb0-9a74-9cc24d1b2e13@github.com> On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible I might have raised this question before. In my opinion, the scrolling in these virtualized views should be more or less equivalent to the scrolling in the ScrollPane. In other words, using thumb track to page down and then page up (or using PgUp/PgDn keys) should get the control to its original state, unless it hit the rail. This is how it's currently works in MS Word (which isn't exactly a pinnacle of usability, but something a lot of people across the globe use routinely). See here using Design -> Paragraph Spacing popup, notice how the initial state is not aligned exactly at the top of the cell, clicking on the track below the thumb to page down, then above the thumb to page up, we arrive at the same exact position: ![Screenshot 2024-05-06 at 10 29 00](https://github.com/openjdk/jfx/assets/107069028/a0240022-1895-4d95-b2ad-18aa3bfc7fa5) ![Screenshot 2024-05-06 at 10 29 08](https://github.com/openjdk/jfx/assets/107069028/3b303ee2-7f73-4370-ad64-857faa9922f4) ![Screenshot 2024-05-06 at 10 29 15](https://github.com/openjdk/jfx/assets/107069028/7ee1d100-4220-42f6-94e4-abb58d0c0ddf) diff 1 and 3: ![Screenshot 2024-05-06 at 10 30 41](https://github.com/openjdk/jfx/assets/107069028/561c0333-2a9f-4547-a278-a6935600d93b) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2096570758 From kcr at openjdk.org Mon May 6 17:51:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 17:51:58 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: References: Message-ID: <7XC_CXDHr5jLwO8ixdRUBN7G8aoGZK-BUJi_MwwkjYI=.28ebf6e7-1da8-4158-9e9c-a0d7ff98bc3d@github.com> On Mon, 6 May 2024 16:26:42 GMT, Andy Goryachev wrote: >> This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. > > modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: > >> 415: * integer values. >> 416: *

>> 417: * If {@link #wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from > > The link for wrapAround does not resolve in Eclipse. > I'd suggest to change it to > > * If {@link SpinnerValueFactory#wrapAround wrapAround} > > > Same comment applies to the min and max in line 420. I don't think this will help. This is the same issue I mentioned in PR #1389 -- you need to link to the property _method_, so I think changing to the following will do it: * If {@link #wrapAroundProperty wrapAround} (it shouldn't be necessary to qualify it with the enclosing class, but it wouldn't hurt to do so) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591345778 From duke at openjdk.org Mon May 6 17:57:00 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 17:57:00 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: <-nVZm7uQ_QQaaifVJkycRSn5Qa2lNgJkGOI45vHMTrY=.7f744dab-08ba-4efb-a00d-ebe6d5b5b96c@github.com> On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible I agree with you, at least with scrolling when clicking on the scrollbar track. I would like to change the amount of scroll pixels to the viewport length. PageUp/PageDown not only scrolls the view, but also moves the selection/focus, so it makes sense to align the cells up/down. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2096601060 From angorya at openjdk.org Mon May 6 18:02:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 18:02:00 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: <7XC_CXDHr5jLwO8ixdRUBN7G8aoGZK-BUJi_MwwkjYI=.28ebf6e7-1da8-4158-9e9c-a0d7ff98bc3d@github.com> References: <7XC_CXDHr5jLwO8ixdRUBN7G8aoGZK-BUJi_MwwkjYI=.28ebf6e7-1da8-4158-9e9c-a0d7ff98bc3d@github.com> Message-ID: <-qvl3_XSg_aAx8N59nUQp4zzsc25jqSTZtMWJIUlN2E=.3929dda8-87ea-44b4-9ed0-08e20239bb49@github.com> On Mon, 6 May 2024 17:39:33 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: >> >>> 415: * integer values. >>> 416: *

>>> 417: * If {@link #wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from >> >> The link for wrapAround does not resolve in Eclipse. >> I'd suggest to change it to >> >> * If {@link SpinnerValueFactory#wrapAround wrapAround} >> >> >> Same comment applies to the min and max in line 420. > > I don't think this will help. This is the same issue I mentioned in PR #1389 -- you need to link to the property _method_, so I think changing to the following will do it: > > > * If {@link #wrapAroundProperty wrapAround} > > > (it shouldn't be necessary to qualify it with the enclosing class, but it wouldn't hurt to do so) `{@link #wrapAroundProperty wrapAround}` does not resolve **in Eclipse** (it does in javadoc output). This might be Eclipse limitation, but it would be awfully nice to have it resolved in Eclipse. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591370127 From angorya at openjdk.org Mon May 6 18:07:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 18:07:58 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: <-nVZm7uQ_QQaaifVJkycRSn5Qa2lNgJkGOI45vHMTrY=.7f744dab-08ba-4efb-a00d-ebe6d5b5b96c@github.com> References: <-nVZm7uQ_QQaaifVJkycRSn5Qa2lNgJkGOI45vHMTrY=.7f744dab-08ba-4efb-a00d-ebe6d5b5b96c@github.com> Message-ID: On Mon, 6 May 2024 17:54:44 GMT, eduardsdv wrote: > PageUp/PageDown not only scrolls the view, but also moves the selection/focus, so it makes sense to align the cells up/down. You are right about focus/selection! This brings up another question: for accessibility reasons, do we want to add key bindings for the vertical scrolling in addition to the horizontal ones in #1393 ? For example, when the cell height exceeds the viewport height, there should be a way to scroll the content vertically using unit increment via keyboard only. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2096617895 From kcr at openjdk.org Mon May 6 18:21:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 18:21:56 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. I get the following internal assertion failure when running the test on Linux: NestedEventLoopTest > testCanExitAndThenEnterNewLoop FAILED java.lang.AssertionError: Internal inconsistency - wrong EventLoop at javafx.graphics at 23-ea/com.sun.glass.ui.EventLoop.enter(EventLoop.java:108) at javafx.graphics at 23-ea/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:656) at javafx.graphics at 23-ea/javafx.application.Platform.enterNestedEventLoop(Platform.java:310) at test.javafx.stage.NestedEventLoopTest.lambda$testCanExitAndThenEnterNewLoop$29(NestedEventLoopTest.java:326 It ran cleanly on Mac and Windows. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2096641134 From duke at openjdk.org Mon May 6 18:38:02 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 18:38:02 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible It would be nice if it possible to scroll with the keyboard without moving the selection/focus. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2096666336 From duke at openjdk.org Mon May 6 18:48:59 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 18:48:59 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: Message-ID: On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > 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 14 additional commits since the last revision: > > - tests > - cleanup > - node orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - table view behavior > - tree view behavior > - list view behavior > - orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - Merge branch 'master' into 8313138.horizontal > - ... and 4 more: https://git.openjdk.org/jfx/compare/07a85ee2...5bae5e7a modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListViewSkin.java line 686: > 684: right = !right; > 685: } > 686: ScrollBar sb = flow.getHbar(); The ListView has the orientation property ``ListView.setOrientation(Orientation)``. I think it should be ScrollBar sb = flow.isVertical() ? flow.getHbar() : flow.getVbar(); and the name of the method something like ``crossUnitScroll(boolean)``. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1393#discussion_r1591418338 From duke at openjdk.org Mon May 6 18:51:59 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 18:51:59 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: Message-ID: On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > 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 14 additional commits since the last revision: > > - tests > - cleanup > - node orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - table view behavior > - tree view behavior > - list view behavior > - orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - Merge branch 'master' into 8313138.horizontal > - ... and 4 more: https://git.openjdk.org/jfx/compare/55618355...5bae5e7a What about the ``GridView``? It also uses the ``VirtualFlow``. Should it also support this kind of scrolling? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2096689208 From angorya at openjdk.org Mon May 6 18:55:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 18:55:00 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: Message-ID: <-CpuzgBaacUxb6oWITYinax1RssLgvV8s8d9VrLIlqs=.284b57b3-8bd4-493e-b56c-bb03789bf9f5@github.com> On Mon, 6 May 2024 18:49:04 GMT, eduardsdv wrote: > What about the `GridView` What's a GridView? ControlsFX is not a part of OpenJFX... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2096694208 From duke at openjdk.org Mon May 6 19:00:59 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 6 May 2024 19:00:59 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: <-CpuzgBaacUxb6oWITYinax1RssLgvV8s8d9VrLIlqs=.284b57b3-8bd4-493e-b56c-bb03789bf9f5@github.com> References: <-CpuzgBaacUxb6oWITYinax1RssLgvV8s8d9VrLIlqs=.284b57b3-8bd4-493e-b56c-bb03789bf9f5@github.com> Message-ID: On Mon, 6 May 2024 18:52:10 GMT, Andy Goryachev wrote: > > What about the `GridView` > > What's a GridView? ControlsFX is not a part of OpenJFX... Oh, sorry, my mistake. You are right. It is part of the ControlsFX. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2096703376 From angorya at openjdk.org Mon May 6 20:03:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 20:03:03 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: Message-ID: <1Jc_cSVu5329YdV2LAGiDnsw5v_LMlpFw-OUvNMPR5Q=.abc0c114-fb2d-4e82-a45b-e28c98d78fa7@github.com> On Mon, 6 May 2024 18:46:33 GMT, eduardsdv wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: >> >> - tests >> - cleanup >> - node orientation >> - Merge remote-tracking branch 'origin/master' into 8313138.horizontal >> - table view behavior >> - tree view behavior >> - list view behavior >> - orientation >> - Merge remote-tracking branch 'origin/master' into 8313138.horizontal >> - Merge branch 'master' into 8313138.horizontal >> - ... and 4 more: https://git.openjdk.org/jfx/compare/3483d28c...5bae5e7a > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListViewSkin.java line 686: > >> 684: right = !right; >> 685: } >> 686: ScrollBar sb = flow.getHbar(); > > The ListView has the orientation property ``ListView.setOrientation(Orientation)``. > I think it should be > > ScrollBar sb = flow.isVertical() ? flow.getHbar() : flow.getVbar(); > > and the name of the method something like ``crossUnitScroll(boolean)``. I am afraid this suggestion is incorrect: the new key bindings affect horizontal scroll bar regardless of the orientation. The new behavior can be checked with the Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1393#discussion_r1591492253 From angorya at openjdk.org Mon May 6 20:25:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 20:25:59 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: Message-ID: On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > 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 14 additional commits since the last revision: > > - tests > - cleanup > - node orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - table view behavior > - tree view behavior > - list view behavior > - orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - Merge branch 'master' into 8313138.horizontal > - ... and 4 more: https://git.openjdk.org/jfx/compare/3ef18774...5bae5e7a ... but nothing should prevent the maintainers of ControlsFx from adding this functionality to the GridView. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2096838107 From angorya at openjdk.org Mon May 6 20:25:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 20:25:59 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5] In-Reply-To: References: <-CpuzgBaacUxb6oWITYinax1RssLgvV8s8d9VrLIlqs=.284b57b3-8bd4-493e-b56c-bb03789bf9f5@github.com> Message-ID: On Mon, 6 May 2024 18:57:57 GMT, eduardsdv wrote: >>> What about the `GridView` >> >> What's a GridView? ControlsFX is not a part of OpenJFX... > >> > What about the `GridView` >> >> What's a GridView? ControlsFX is not a part of OpenJFX... > > Oh, sorry, my mistake. You are right. It is part of the ControlsFX. As @eduardsdv mentioned in https://github.com/openjdk/jfx/pull/1326#issuecomment-2096666336 and @kevinrushforth asked about earlier, perhaps we should add similar capability for vertical scrolling using alt-ctrl-Up/DOWN (option-command-UP/DOWN) in the same PR rather than separately. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2096841533 From mfox at openjdk.org Mon May 6 21:14:08 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 6 May 2024 21:14:08 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. I'll look into the Linux failure. The core EventLoop code passes an object into the application's leaveNestedEventLoop and expects to see that object returned from the applications's matching enterNestedEventLoop call. On Mac and Windows this object is passed through to glass as an argument on the stack. On Linux this value is handled as an application global. I suspect the Linux bookkeeping isn't robust enough to handle this case but it will take a bit to nail down the details. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2096926552 From duke at openjdk.org Mon May 6 21:32:07 2024 From: duke at openjdk.org (drmarmac) Date: Mon, 6 May 2024 21:32:07 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: > This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. drmarmac has updated the pull request incrementally with one additional commit since the last revision: javaDoc updates according to code review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1450/files - new: https://git.openjdk.org/jfx/pull/1450/files/c491f8b8..0ecdfae1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1450&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1450&range=00-01 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1450.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1450/head:pull/1450 PR: https://git.openjdk.org/jfx/pull/1450 From duke at openjdk.org Mon May 6 21:32:07 2024 From: duke at openjdk.org (drmarmac) Date: Mon, 6 May 2024 21:32:07 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 16:27:52 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 420: >> >>> 418: * the minimum value to the maximum value (and vice versa). As a consequence of that, the number >>> 419: * of steps required to wrap around to the same value is N+1, where N is the number of steps between >>> 420: * {@link #min} (inclusive) and {@link #max} (inclusive). >> >> Suggestion: It might be helpful to show the equation: >> >> >> val = (val + delta) % (max - min + 1) > > a good idea agreed, I used "amountToStepBy" instead of "delta" here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591576774 From duke at openjdk.org Mon May 6 21:37:57 2024 From: duke at openjdk.org (drmarmac) Date: Mon, 6 May 2024 21:37:57 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: <-qvl3_XSg_aAx8N59nUQp4zzsc25jqSTZtMWJIUlN2E=.3929dda8-87ea-44b4-9ed0-08e20239bb49@github.com> References: <7XC_CXDHr5jLwO8ixdRUBN7G8aoGZK-BUJi_MwwkjYI=.28ebf6e7-1da8-4158-9e9c-a0d7ff98bc3d@github.com> <-qvl3_XSg_aAx8N59nUQp4zzsc25jqSTZtMWJIUlN2E=.3929dda8-87ea-44b4-9ed0-08e20239bb49@github.com> Message-ID: On Mon, 6 May 2024 17:59:14 GMT, Andy Goryachev wrote: >> I don't think this will help. This is the same issue I mentioned in PR #1389 -- you need to link to the property _method_, so I think changing to the following will do it: >> >> >> * If {@link #wrapAroundProperty wrapAround} >> >> >> (it shouldn't be necessary to qualify it with the enclosing class, but it wouldn't hurt to do so) > > `{@link #wrapAroundProperty wrapAround}` does not resolve **in Eclipse** (it does in javadoc output). > > This might be Eclipse limitation, but it would be awfully nice to have it resolved in Eclipse. I also fixed the min/max links to refer to minProperty/maxProperty. IntelliJ IDEA has the same problem as eclipse. I guess this has to do with the "javafx" option to the javadoc command (build.gradle:4286 `options.addBooleanOption("javafx").setValue(true);`) that seems to allow to use the private fields' docs for the properties, by naming convention? Maybe we need to file issues in Eclipse/IntelliJ for this so they add the option to their javadoc renderer. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591581530 From angorya at openjdk.org Mon May 6 21:50:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 21:50:00 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 21:32:07 GMT, drmarmac wrote: >> This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > javaDoc updates according to code review modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: > 415: * integer values. > 416: *

> 417: * If {@link #wrapAroundProperty wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from wrapAround still does not work in Eclipse, but this does, while providing the same visuals: {@link SpinnerValueFactory#wrapAroundProperty wrapAround} does it work in intellij? modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 620: > 618: * double values. > 619: *

> 620: * If {@link #wrapAroundProperty wrapAround} is {@code true}, the {@code DoubleSpinnerValueFactory} will step same here ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591590066 PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591590894 From angorya at openjdk.org Mon May 6 22:00:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 22:00:27 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v6] In-Reply-To: References: Message-ID: > Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. > > **NOTE: For controls in right-to-left orientation, the direction is reversed.** > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > > > Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. 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 16 additional commits since the last revision: - added vertical scrolling - Merge branch 'master' into 8313138.horizontal - tests - cleanup - node orientation - Merge remote-tracking branch 'origin/master' into 8313138.horizontal - table view behavior - tree view behavior - list view behavior - orientation - ... and 6 more: https://git.openjdk.org/jfx/compare/969d0b8e...859f7bbd ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1393/files - new: https://git.openjdk.org/jfx/pull/1393/files/5bae5e7a..859f7bbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=04-05 Stats: 5171 lines in 211 files changed: 4184 ins; 503 del; 484 mod Patch: https://git.openjdk.org/jfx/pull/1393.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1393/head:pull/1393 PR: https://git.openjdk.org/jfx/pull/1393 From angorya at openjdk.org Mon May 6 23:14:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 May 2024 23:14:11 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: References: Message-ID: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> > Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. > > **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > public void verticalUnitScroll(boolean down); > > > Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: vertical scrolling tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1393/files - new: https://git.openjdk.org/jfx/pull/1393/files/859f7bbd..eeaa8d91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=05-06 Stats: 156 lines in 4 files changed: 146 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1393.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1393/head:pull/1393 PR: https://git.openjdk.org/jfx/pull/1393 From kcr at openjdk.org Mon May 6 23:24:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 23:24:54 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: <7XC_CXDHr5jLwO8ixdRUBN7G8aoGZK-BUJi_MwwkjYI=.28ebf6e7-1da8-4158-9e9c-a0d7ff98bc3d@github.com> <-qvl3_XSg_aAx8N59nUQp4zzsc25jqSTZtMWJIUlN2E=.3929dda8-87ea-44b4-9ed0-08e20239bb49@github.com> Message-ID: On Mon, 6 May 2024 21:35:40 GMT, drmarmac wrote: >> `{@link #wrapAroundProperty wrapAround}` does not resolve **in Eclipse** (it does in javadoc output). >> >> This might be Eclipse limitation, but it would be awfully nice to have it resolved in Eclipse. > > I also fixed the min/max links to refer to minProperty/maxProperty. IntelliJ IDEA has the same problem as eclipse. I guess this has to do with the "javafx" option to the javadoc command (build.gradle:4286 `options.addBooleanOption("javafx").setValue(true);`) that seems to allow to use the private fields' docs for the properties, by naming convention? Maybe we need to file issues in Eclipse/IntelliJ for this so they add the option to their javadoc renderer. There are two issues here. The first is that you cannot just link to a `xxx` property by name -- you have to link to the `xxxProperty` method. The former doesn't work in the generated javadocs either (so it's not just an IDE problem). The second issue seems specific to Eclipse, in that if you don't prefix the method name with the name of the enclosing (outer) class, Eclipse doesn't generate the link. That seems like an Eclipse bug to me, but as Andy points out, it's a trivial thing to add the class name (and won't affect the output). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591647400 From kcr at openjdk.org Mon May 6 23:24:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 May 2024 23:24:55 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 21:46:29 GMT, Andy Goryachev wrote: >> drmarmac has updated the pull request incrementally with one additional commit since the last revision: >> >> javaDoc updates according to code review > > modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: > >> 415: * integer values. >> 416: *

>> 417: * If {@link #wrapAroundProperty wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from > > wrapAround still does not work in Eclipse, but this does, while providing the same visuals: > > > {@link SpinnerValueFactory#wrapAroundProperty wrapAround} > > > does it work in intellij? That one should work everywhere, since it is equivalent. Worth double-checking, though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591647816 From duke at openjdk.org Tue May 7 05:14:58 2024 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 7 May 2024 05:14:58 GMT Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: <2EsKiHrk7mzYnr8i3i-cQSAfsvpqrh2UVIvC_OLnzLA=.5eb3d1ad-8fee-471c-865e-9eae69387d55@github.com> On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao wrote: > Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration. > > It seems i3 replies with decorated sizes, even if window is not decorated. > > Won't hurt other WMs. I can confirm on my system that this PR fixes the issues that I am seeing and some users reported. Here is a before and after comparison for context menus and tooltips: ![image](https://github.com/openjdk/jfx/assets/72509152/11f8a791-3777-4e52-b318-f994fe465d69) ![image](https://github.com/openjdk/jfx/assets/72509152/1553b2aa-e4da-45b2-a99b-6664270dbd54) ![image](https://github.com/openjdk/jfx/assets/72509152/066b685e-f591-4d21-bdff-ebe1ffdd2937) ![image](https://github.com/openjdk/jfx/assets/72509152/15151785-5e53-442d-a685-a99bea6a51e5) The tests also pass for me (didn't build webkit though) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2097459748 From duke at openjdk.org Tue May 7 06:09:07 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 7 May 2024 06:09:07 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v3] In-Reply-To: References: Message-ID: > This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. drmarmac has updated the pull request incrementally with one additional commit since the last revision: javaDoc: Qualify property links ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1450/files - new: https://git.openjdk.org/jfx/pull/1450/files/0ecdfae1..407becbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1450&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1450&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1450.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1450/head:pull/1450 PR: https://git.openjdk.org/jfx/pull/1450 From duke at openjdk.org Tue May 7 06:14:58 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 7 May 2024 06:14:58 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 23:22:36 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java line 417: >> >>> 415: * integer values. >>> 416: *

>>> 417: * If {@link #wrapAroundProperty wrapAround} is {@code true}, the {@code IntegerSpinnerValueFactory} will step from >> >> wrapAround still does not work in Eclipse, but this does, while providing the same visuals: >> >> >> {@link SpinnerValueFactory#wrapAroundProperty wrapAround} >> >> >> does it work in intellij? > > That one should work everywhere, since it is equivalent. Worth double-checking, though. Updated. I checked this variant with IntelliJ: While I can follow the link, it doesn't show the wrapAround field's javadoc, just the wrapAroundProperty's javadoc which is empty. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1591862720 From arapte at openjdk.org Tue May 7 06:36:04 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 7 May 2024 06:36:04 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: <2CZH-_xws9Mh9aKWHS5WPG-QtINWabtfcJKFEWU6C4s=.6a347edc-858c-4d82-8933-e3cb75bfbbe2@github.com> On Thu, 2 May 2024 23:35:12 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Streamline WinTextRangeProviderTest > > Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 Marked as reviewed by arapte (Reviewer). >Thank you. I committed at https://github.com/openjdk/jfx/commit/d03bdd40a3340bd85397fe2ceaa7f053a58da6c5 (with you as author, hope this is in line with the policies?!). Thanks @koppor, the fix looks good. That's a great gesture, thanks, but I was just reviewing the changes, you don't have to add me as a contributor. Thanks for your contribution, Approving.! ------------- PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2042177454 PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2097548737 From mstrauss at openjdk.org Tue May 7 07:34:57 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 May 2024 07:34:57 GMT Subject: RFR: 8331616: ChangeListener is not triggered when the InvalidationListener is removed In-Reply-To: References: Message-ID: On Fri, 3 May 2024 14:45:24 GMT, John Hendrikx wrote: > This PR provides a fix for the linked issue. > > The issue was that when an invalidation listener is removed, and the `ExpressionHelper` type changes from `Generic` to `SingleChange` that it would copy the current value of the `Generic` instance before it was updated (this is because invalidation listeners trigger before change listeners and the current value would only be updated **after** invalidation listeners notifications were completed). > > The code now will update the current value before sending out any notifications **if** there are change listeners present to head off this problem. > > Added a few test cases to verify this. > > Note: the PR which replaces `ExpressionHelper` does not have this problem: https://github.com/openjdk/jfx/pull/1081 The fix works as expected. However, I hope that we can get #1081 in as a replacement. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1448#pullrequestreview-2042311784 From michaelstrau2 at gmail.com Tue May 7 08:44:23 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 7 May 2024 10:44:23 +0200 Subject: Proposal: Public InputMap (v2) In-Reply-To: References: Message-ID: Hi Andy! The updated proposal seems to be a slight refinement of the original proposal, and I think most of the points raised in the previous discussion still stand. As it is, I still think that this is an exceptionally large API surface for what the feature can actually bring to the table. It's overly specific in trying to solve problems for which general-purpose APIs like event handlers can be extended to work just as well (and open up many more use cases than just those of a bespoke control API). The fact that the API tries to fix a problem with the event system itself (unpredictable invocation order) is a red flag. We should fix this problem where it originates, which is the event API; crafting workaround APIs in other parts of JavaFX doesn't seem to be the right approach to me. This would also help to break the problem down into more manageable chunks: improve the event system first, then see how that influences the remaining problems that need to be solved. You provide several examples of what the InputMap API can do: 1. Adding a new key mapping // creates a new key binding mapped to an external function control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> { externalFunction(); }); I don't see why this is needed. It doesn't seem to be easier than using a plain old event handler, it's just different. 2. Redefine an existing function // redefine function keeping existing key mappings getInputMap().registerFunction(Tag.COPY, (control) -> customCopy()); If I want to change the meaning of the copy() method, can I not just override the method and provide my own implementation? Plain old Java seems to do the job. 3. Map an existing function to a new binding // map a new key binding control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), Tag.COPY); Again, an event handler would do the job here. 4. Obtain the default function // obtains the default function handler FunctionHandler h = getInputMap().getDefaultFunction(Tag.COPY); If I override the copy() method to provide my own implementation, I could also add a defaultCopy() method that calls the base implementation. Then I can call both copy() and defaultCopy(). (I don't know why I would want to do this, though.) To summarize: the way I see it, your examples don't provide a compelling reason why we need this new API. Given the size and complexity of the proposal, I suggest to break the problem down into more manageable parts, and solve the most fundamental issues first. At the very least, the issue with event invocation ordering should be solved in the event system. On Mon, Mar 11, 2024 at 4:22?PM Andy Goryachev wrote: > > Dear JavaFX developers: > > > > Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were: > > > > desire for some static behavior to avoid the per-instance penalty > clearer separation of concerns between controls, skins, and behaviors > desire to have some sort of public API for behaviors > need for addressing an issue with the event handler execution order between application and skins > > > > I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include: > > > > separation of SkinInputMap from the control's InputMap > enabling static skin input maps for stateless behaviors > explicit priority levels for event handlers and key mappings created by the application and by the skin > > > > The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls: > > > > complex popup-like controls: ComboBox, ColorPicker, DatePicker > complex text input controls: PasswordField, TextArea, TextField > control with a stateless behavior: TabPane > > > > as well as a brand new RichTextArea control being incubated [8]. > > > > Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. > > > > For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below. > > > > What do you think? > > -andy > > > > > > References > > > > [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md > > [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md > > [2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ > > [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395 > > [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 > > [5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior > > [6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md > > [7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html > > [8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > From mstrauss at openjdk.org Tue May 7 09:05:03 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 May 2024 09:05:03 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 15:23:20 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > comments modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 236: > 234: OverrunStyle type, > 235: String ellipsisString, > 236: AtomicBoolean textTruncated Instead of returning the clipped text with the return value, and the truncation flag with an argument, have you considered just using a record to return both at the same time? That would be a cleaner solution. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592079493 From fkirmaier at openjdk.org Tue May 7 09:39:23 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 7 May 2024 09:39:23 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Use viewport length as block increment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/6a02f682..3972d8ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=02-03 Stats: 69 lines in 4 files changed: 26 ins; 25 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From duke at openjdk.org Tue May 7 09:47:05 2024 From: duke at openjdk.org (eduardsdv) Date: Tue, 7 May 2024 09:47:05 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v3] In-Reply-To: References: <-nVZm7uQ_QQaaifVJkycRSn5Qa2lNgJkGOI45vHMTrY=.7f744dab-08ba-4efb-a00d-ebe6d5b5b96c@github.com> Message-ID: On Mon, 6 May 2024 18:05:06 GMT, Andy Goryachev wrote: >> I agree with you, at least with scrolling when clicking on the scrollbar track. >> I would like to change the amount of scroll pixels to the viewport length. >> >> PageUp/PageDown not only scrolls the view, but also moves the selection/focus, so it makes sense to align the cells up/down. > >> PageUp/PageDown not only scrolls the view, but also moves the selection/focus, so it makes sense to align the cells up/down. > > You are right about focus/selection! > > This brings up another question: for accessibility reasons, do we want to add key bindings for the vertical scrolling in addition to the horizontal ones in #1393 ? For example, when the cell height exceeds the viewport height, there should be a way to scroll the content vertically using unit increment via keyboard only. > > What do you think? I followed @andy-goryachev-oracle's suggestion and changed the block increment to the viewport length. I also fixed the scroll behavior for the case described in my comment https://github.com/openjdk/jfx/pull/1326#discussion_r1591327052. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2097885886 From duke at openjdk.org Tue May 7 09:47:06 2024 From: duke at openjdk.org (eduardsdv) Date: Tue, 7 May 2024 09:47:06 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: <93glvnrAGyUNkE9aGVlbP7Jj8TJwlQ0ZoFYd3GU9FN8=.04143a04-74ff-44a4-a1cf-b884420ca854@github.com> On Tue, 7 May 2024 09:39:23 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Use viewport length as block increment In my opinion, this PR is now ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2097889180 From kpk at openjdk.org Tue May 7 10:15:11 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 May 2024 10:15:11 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll Message-ID: The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the item list. Fixed the issue by restoring the selection in this case. Added a unit test to validate the fix ------------- Commit messages: - Fix item selection issue Changes: https://git.openjdk.org/jfx/pull/1452/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279140 Stats: 33 lines in 2 files changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1452.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1452/head:pull/1452 PR: https://git.openjdk.org/jfx/pull/1452 From kpk at openjdk.org Tue May 7 12:01:58 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 May 2024 12:01:58 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll In-Reply-To: References: Message-ID: On Tue, 7 May 2024 10:10:23 GMT, Karthik P K wrote: > The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the item list. Fixed the issue by restoring the selection in this case. > > Added a unit test to validate the fix I missed to validate the test case present in [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) and looks like it is not yet fixed. Hence I will change this PR to draft for now ------------- PR Comment: https://git.openjdk.org/jfx/pull/1452#issuecomment-2098238722 From angorya at openjdk.org Tue May 7 14:41:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 14:41:00 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: <83KQn782Xo5JKjzx894ruRGFP-zP2QmxL7Aax592en0=.df2799e8-8361-4e96-8a33-29cb4db83125@github.com> On Tue, 7 May 2024 09:02:49 GMT, Michael Strau? wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 236: > >> 234: OverrunStyle type, >> 235: String ellipsisString, >> 236: AtomicBoolean textTruncated > > Instead of returning the clipped text with the return value, and the truncation flag with an argument, have you considered just using a record to return both at the same time? That would be a cleaner solution. Not really a cleaner solution: `computeClippedWrappedText()` might get called multiple times (for each line of text), and doing an extra allocation per call is less optimal than passing a reference to an AtomicBoolean. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592604175 From kpk at openjdk.org Tue May 7 15:00:03 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 May 2024 15:00:03 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Mon, 6 May 2024 15:23:20 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > comments Looks good to me overall. Added a minor comment inline. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 218: > 216: * Computes the actual text to be shown in the Labeled with the text wrapping disabled: > 217: * unmodified if it fits into available area, > 218: * or with the ellipsis string inserted into strategic place(s) if it does not. ellipsis string can be referenced similar to textTruncated? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 446: > 444: * Computes the actual text to be shown in the Labeled with the text wrapping enabled: > 445: * unmodified if it fits into available area, > 446: * or with the ellipsis string inserted into strategic place(s) if it does not. Similar to previous comment. ellipsis string can be referenced similar to textTruncated? ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2043344480 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592565769 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592566139 From angorya at openjdk.org Tue May 7 15:00:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 15:00:04 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 14:18:29 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 218: > >> 216: * Computes the actual text to be shown in the Labeled with the text wrapping disabled: >> 217: * unmodified if it fits into available area, >> 218: * or with the ellipsis string inserted into strategic place(s) if it does not. > > ellipsis string can be referenced similar to textTruncated? Can you please clarify your question? I don't understand. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592637109 From angorya at openjdk.org Tue May 7 15:07:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 15:07:57 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v3] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 06:09:07 GMT, drmarmac wrote: >> This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > javaDoc: Qualify property links Looks good in Eclipse and in the browser. Thank you for making the doc clearer and also for fixing the issue! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1450#pullrequestreview-2043468092 From kcr at openjdk.org Tue May 7 15:30:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 15:30:57 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v3] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 06:09:07 GMT, drmarmac wrote: >> This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > javaDoc: Qualify property links Looks good to me, too. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1450#pullrequestreview-2043526948 From kcr at openjdk.org Tue May 7 15:30:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 15:30:58 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: Message-ID: <7tYpLotQAh6fQDEC7ZodZkhkF-kW5EmT4c_xOMQgum0=.b779ecd5-7152-46fa-9a87-bf6eb504eb3b@github.com> On Tue, 7 May 2024 06:11:59 GMT, drmarmac wrote: >> That one should work everywhere, since it is equivalent. Worth double-checking, though. > > Updated. I checked this variant with IntelliJ: While I can follow the link, it doesn't show the wrapAround field's javadoc, just the wrapAroundProperty's javadoc which is empty. I guess that's because IntelliJ doesn't process the javafx properties. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1592684421 From kpk at openjdk.org Tue May 7 15:34:00 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 May 2024 15:34:00 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 14:56:57 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 218: >> >>> 216: * Computes the actual text to be shown in the Labeled with the text wrapping disabled: >>> 217: * unmodified if it fits into available area, >>> 218: * or with the ellipsis string inserted into strategic place(s) if it does not. >> >> ellipsis string can be referenced similar to textTruncated? > > Can you please clarify your question? I don't understand. I wanted to check, In this line: "or with the ellipsis string inserted into strategic place(s) if it does not.", can we add reference to ellipsisString parameter similar to how we have reference to textTruncated parameter. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592685851 From kcr at openjdk.org Tue May 7 15:34:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 15:34:00 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 15:28:56 GMT, Karthik P K wrote: >> Can you please clarify your question? I don't understand. > > I wanted to check, In this line: "or with the ellipsis string inserted into strategic place(s) if it does not.", can we add reference to ellipsisString parameter similar to how we have reference to textTruncated parameter. While that would be an OK change, this is an internal method, so it really doesn't much matter -- the docs are only seen by those looking at the code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592689074 From andy.goryachev at oracle.com Tue May 7 15:35:25 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 7 May 2024 15:35:25 +0000 Subject: Proposal: Public InputMap (v2) In-Reply-To: References: Message-ID: Dear Michael: Thank you for a thoughtful feedback! You are correct - the new proposal is a variation of the old one, with modifications intended to address the earlier use cases identified by you and John, namely the event handler priority and the stateless behaviors. The reason I propose to solve the even priority issue in the Control and its InputMap is simply because I think this is the only place where we have multiple actors shuffling the event handlers: we have the application initial configuration, we have the old skin, possibly the new skin that replaces the old one, and we might have user settings being restored at run time. I thought the new design addresses these use cases nicely, but it looks like you believe there are use cases that require explicit prioritization of event handlers for things other than Controls. Can you provide an example please? As for the second part (items 1-4), I suspect you might be still not considering a use case of user customization at run time or from settings. To give an example, in the context of a text editor, the user may want to map Ctrl-D to a DELETE_PARAGRAPH function, or not, as a part of user-set key bindings (or map some other key combination). While I suppose it's possible to support this requirement by adding and removing a key event handler (one per key?), the InputMap provides a uniform and a rather convenient API. Similarly, the application requirements might call for runtime unmapping of user bindings, in which case we want an easy API to undo the change and revert back to the default functionality. Sure, we can juggle the event handlers, but again, the InputMap provides a nice API for that. Having said all that, I am not particularly against adding prioritization scheme to every event handler (I just think it is unnecessary, but I trust you will provide a good example shortly). Thank you -andy From: openjfx-dev on behalf of Michael Strau? Date: Tuesday, May 7, 2024 at 01:44 To: Cc: openjfx-dev at openjdk.org Subject: Re: Proposal: Public InputMap (v2) Hi Andy! The updated proposal seems to be a slight refinement of the original proposal, and I think most of the points raised in the previous discussion still stand. As it is, I still think that this is an exceptionally large API surface for what the feature can actually bring to the table. It's overly specific in trying to solve problems for which general-purpose APIs like event handlers can be extended to work just as well (and open up many more use cases than just those of a bespoke control API). The fact that the API tries to fix a problem with the event system itself (unpredictable invocation order) is a red flag. We should fix this problem where it originates, which is the event API; crafting workaround APIs in other parts of JavaFX doesn't seem to be the right approach to me. This would also help to break the problem down into more manageable chunks: improve the event system first, then see how that influences the remaining problems that need to be solved. You provide several examples of what the InputMap API can do: 1. Adding a new key mapping // creates a new key binding mapped to an external function control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> { externalFunction(); }); I don't see why this is needed. It doesn't seem to be easier than using a plain old event handler, it's just different. 2. Redefine an existing function // redefine function keeping existing key mappings getInputMap().registerFunction(Tag.COPY, (control) -> customCopy()); If I want to change the meaning of the copy() method, can I not just override the method and provide my own implementation? Plain old Java seems to do the job. 3. Map an existing function to a new binding // map a new key binding control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), Tag.COPY); Again, an event handler would do the job here. 4. Obtain the default function // obtains the default function handler FunctionHandler h = getInputMap().getDefaultFunction(Tag.COPY); If I override the copy() method to provide my own implementation, I could also add a defaultCopy() method that calls the base implementation. Then I can call both copy() and defaultCopy(). (I don't know why I would want to do this, though.) To summarize: the way I see it, your examples don't provide a compelling reason why we need this new API. Given the size and complexity of the proposal, I suggest to break the problem down into more manageable parts, and solve the most fundamental issues first. At the very least, the issue with event invocation ordering should be solved in the event system. On Mon, Mar 11, 2024 at 4:22?PM Andy Goryachev wrote: > > Dear JavaFX developers: > > > > Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were: > > > > desire for some static behavior to avoid the per-instance penalty > clearer separation of concerns between controls, skins, and behaviors > desire to have some sort of public API for behaviors > need for addressing an issue with the event handler execution order between application and skins > > > > I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include: > > > > separation of SkinInputMap from the control's InputMap > enabling static skin input maps for stateless behaviors > explicit priority levels for event handlers and key mappings created by the application and by the skin > > > > The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls: > > > > complex popup-like controls: ComboBox, ColorPicker, DatePicker > complex text input controls: PasswordField, TextArea, TextField > control with a stateless behavior: TabPane > > > > as well as a brand new RichTextArea control being incubated [8]. > > > > Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. > > > > For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below. > > > > What do you think? > > -andy > > > > > > References > > > > [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md > > [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md > > [2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ > > [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395 > > [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 > > [5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior > > [6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md > > [7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html > > [8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue May 7 15:41:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 15:41:57 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: <7tYpLotQAh6fQDEC7ZodZkhkF-kW5EmT4c_xOMQgum0=.b779ecd5-7152-46fa-9a87-bf6eb504eb3b@github.com> References: <7tYpLotQAh6fQDEC7ZodZkhkF-kW5EmT4c_xOMQgum0=.b779ecd5-7152-46fa-9a87-bf6eb504eb3b@github.com> Message-ID: On Tue, 7 May 2024 15:27:55 GMT, Kevin Rushforth wrote: >> Updated. I checked this variant with IntelliJ: While I can follow the link, it doesn't show the wrapAround field's javadoc, just the wrapAroundProperty's javadoc which is empty. > > I guess that's because IntelliJ doesn't process the javafx properties. that's why _some say_ eclipse is better: ![Screenshot 2024-05-07 at 08 37 11](https://github.com/openjdk/jfx/assets/107069028/2aa137f6-affc-4aa9-8bcc-c1194d505479) ![Screenshot 2024-05-07 at 08 37 19](https://github.com/openjdk/jfx/assets/107069028/277c6b7a-ab89-4634-83c5-7a6c3178f044) :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1592700203 From angorya at openjdk.org Tue May 7 15:46:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 15:46:18 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v16] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. > > > **Alternative** > > None exists as this requires changes to the core (Utils). > > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: ellipsis string ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/cce514ef..2f131cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=14-15 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Tue May 7 15:46:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 15:46:19 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v15] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 14:18:44 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java line 446: > >> 444: * Computes the actual text to be shown in the Labeled with the text wrapping enabled: >> 445: * unmodified if it fits into available area, >> 446: * or with the ellipsis string inserted into strategic place(s) if it does not. > > Similar to previous comment. ellipsis string can be referenced similar to textTruncated? oh, you want to use `{@code ellipsisString}` instead of the words "ellipsis string", got it. I thought it was clear enough, but yes, can be easily changed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1592703489 From kcr at openjdk.org Tue May 7 15:49:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 15:49:00 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v16] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 15:46:18 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > ellipsis string Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2043570892 From kpk at openjdk.org Tue May 7 15:55:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 7 May 2024 15:55:06 GMT Subject: RFR: 8092102: Labeled: textTruncated property [v16] In-Reply-To: References: Message-ID: <8LiyIymI8f-jcQt9S6XpykN3Y_sCxF2ems3jfP0gSSQ=.4fe56d9f-19a2-4228-b97f-d3d8c45bc690@github.com> On Tue, 7 May 2024 15:46:18 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. >> >> >> **Alternative** >> >> None exists as this requires changes to the core (Utils). >> >> >> **See Also** >> >> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > ellipsis string Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2043582886 From kcr at openjdk.org Tue May 7 16:03:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 16:03:57 GMT Subject: RFR: 8331616: ChangeListener is not triggered when the InvalidationListener is removed In-Reply-To: References: Message-ID: On Fri, 3 May 2024 14:45:24 GMT, John Hendrikx wrote: > This PR provides a fix for the linked issue. > > The issue was that when an invalidation listener is removed, and the `ExpressionHelper` type changes from `Generic` to `SingleChange` that it would copy the current value of the `Generic` instance before it was updated (this is because invalidation listeners trigger before change listeners and the current value would only be updated **after** invalidation listeners notifications were completed). > > The code now will update the current value before sending out any notifications **if** there are change listeners present to head off this problem. > > Added a few test cases to verify this. > > Note: the PR which replaces `ExpressionHelper` does not have this problem: https://github.com/openjdk/jfx/pull/1081 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1448#pullrequestreview-2043602497 From duke at openjdk.org Tue May 7 16:29:59 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 7 May 2024 16:29:59 GMT Subject: RFR: 8331214: Doc: update spec for SpinnerFactory classes [v2] In-Reply-To: References: <7tYpLotQAh6fQDEC7ZodZkhkF-kW5EmT4c_xOMQgum0=.b779ecd5-7152-46fa-9a87-bf6eb504eb3b@github.com> Message-ID: On Tue, 7 May 2024 15:39:29 GMT, Andy Goryachev wrote: >> I guess that's because IntelliJ doesn't process the javafx properties. > > that's why _some say_ eclipse is better: > > ![Screenshot 2024-05-07 at 08 37 11](https://github.com/openjdk/jfx/assets/107069028/2aa137f6-affc-4aa9-8bcc-c1194d505479) > ![Screenshot 2024-05-07 at 08 37 19](https://github.com/openjdk/jfx/assets/107069028/277c6b7a-ab89-4634-83c5-7a6c3178f044) > > :-) I upvoted a matching [issue in the IntelliJ bugtracker](https://youtrack.jetbrains.com/issue/IDEA-273592/JavaFX-incorrectly-navigates-to-property-field-ignores-JavaDoc). As this affects quite a few properties in javafx it would be good to see this fixed at some point. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1450#discussion_r1592767599 From kcr at openjdk.org Tue May 7 16:33:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 16:33:07 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 23:35:12 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Streamline WinTextRangeProviderTest > > Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 The test gets an error on Mac and Linux. See inline comments. tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 56: > 54: @AfterAll > 55: static void shutdown() { > 56: Util.shutdown(); This fails on Mac and Linux because the initialization (and consequently all tests) are skipped, but the call to `Util.shutdown` is not skipped. You will either need to also add `assumeTrue(PlatformUtil.isWindows());` here or else move the `assumeTrue` to the test method. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2043673800 PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592770104 From duke at openjdk.org Tue May 7 16:36:01 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 7 May 2024 16:36:01 GMT Subject: Integrated: 8331214: Doc: update spec for SpinnerFactory classes In-Reply-To: References: Message-ID: On Mon, 6 May 2024 08:24:52 GMT, drmarmac wrote: > This PR updates the javadoc for the SpinnerFactory wrap-around behavior introduced in #1431. This pull request has now been integrated. Changeset: 36e65e8b Author: drmarmac <6900949+drmarmac at users.noreply.github.com> Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/36e65e8b5ef12c6c3eef406d035a985a50000e0a Stats: 23 lines in 1 file changed: 15 ins; 0 del; 8 mod 8331214: Doc: update spec for SpinnerFactory classes Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1450 From angorya at openjdk.org Tue May 7 16:42:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 16:42:10 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> On Tue, 7 May 2024 16:29:33 GMT, Kevin Rushforth wrote: >> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: >> >> Streamline WinTextRangeProviderTest >> >> Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 > > tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 56: > >> 54: @AfterAll >> 55: static void shutdown() { >> 56: Util.shutdown(); > > This fails on Mac and Linux because the initialization (and consequently all tests) are skipped, but the call to `Util.shutdown` is not skipped. You will either need to also add `assumeTrue(PlatformUtil.isWindows());` here or else move the `assumeTrue` to the test method. is there a good way to skip the whole file entirely, e.g. via junit annotation? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592779192 From angorya at openjdk.org Tue May 7 16:42:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 16:42:10 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> Message-ID: On Tue, 7 May 2024 16:37:06 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 56: >> >>> 54: @AfterAll >>> 55: static void shutdown() { >>> 56: Util.shutdown(); >> >> This fails on Mac and Linux because the initialization (and consequently all tests) are skipped, but the call to `Util.shutdown` is not skipped. You will either need to also add `assumeTrue(PlatformUtil.isWindows());` here or else move the `assumeTrue` to the test method. > > is there a good way to skip the whole file entirely, e.g. via junit annotation? maybe https://stackoverflow.com/questions/26115139/junit-ignore-or-skip-entire-test-class ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592783215 From angorya at openjdk.org Tue May 7 17:35:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 17:35:02 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 09:39:23 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Use viewport length as block increment The scrolling finally works as I would expect. Tested with the MonkeyTester using ListView/TableView pages with fixed and variable cell sizes. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1808: > 1806: * @return the value in pixels > 1807: */ > 1808: public double getBlockIncrement() { Adding a new public method, this PR requires CSR. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2043788493 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1592839203 From angorya at openjdk.org Tue May 7 17:39:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 17:39:04 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: <93glvnrAGyUNkE9aGVlbP7Jj8TJwlQ0ZoFYd3GU9FN8=.04143a04-74ff-44a4-a1cf-b884420ca854@github.com> References: <93glvnrAGyUNkE9aGVlbP7Jj8TJwlQ0ZoFYd3GU9FN8=.04143a04-74ff-44a4-a1cf-b884420ca854@github.com> Message-ID: On Tue, 7 May 2024 09:44:08 GMT, eduardsdv wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Use viewport length as block increment > > In my opinion, this PR is now ready. should the contributor info be updated to include @eduardsdv ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2098969047 From kcr at openjdk.org Tue May 7 18:14:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 18:14:00 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 08:55:14 GMT, Florian Kirmaier wrote: >> @FlorianKirmaier I still think this would be a good addition. I believe there is only one open question (from Marius) so it would be great if you can answer that. > > @johanvos > Great to see you would like to see it merged! > I've worked on this topic together with @eduardsdv , > So consider his response to be my answer to the question. @FlorianKirmaier @eduardsdv As @andy-goryachev-oracle mentioned, you will need to file a CSR for the new public method, Please include enough information in the Problem and Solution sections to justify why a new method is needed. The spec (javadoc API documentation) for that new method should indicate its purpose, and needs an `@since 23` tag. Also, please wait for @johanvos to review this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2099025008 From kcr at openjdk.org Tue May 7 18:33:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 18:33:03 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> Message-ID: <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> On Tue, 7 May 2024 16:39:47 GMT, Andy Goryachev wrote: >> is there a good way to skip the whole file entirely, e.g. via junit annotation? > > maybe > https://stackoverflow.com/questions/26115139/junit-ignore-or-skip-entire-test-class > ? We still want to use `assumeTrue` as the pattern (for flexibility), so the question is whether there is a better place besides a method annotated with `@BeforeAll` to put it (which also means duplicating the assumption in the `@AfterAll` method). I'm not aware of one, but maybe someone else is? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592904608 From jvos at openjdk.org Tue May 7 18:45:01 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 7 May 2024 18:45:01 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 09:39:23 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Use viewport length as block increment Good to see this is progressing, I'll do a detailed review later this week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2099080932 From angorya at openjdk.org Tue May 7 18:50:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 18:50:04 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 23:35:12 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Streamline WinTextRangeProviderTest > > Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 The code changes look good to me; don't see any problems testing with Narrator on win11. I do have Deepl installed (though it is not connected due to proxy). See no issues in TextField, PasswordField, TextArea in the test app as well as the Monkey Tester. (once the tests are fixed, I'll re-approve) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2043926383 From duke at openjdk.org Tue May 7 18:50:05 2024 From: duke at openjdk.org (Oliver Kopp) Date: Tue, 7 May 2024 18:50:05 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> Message-ID: On Tue, 7 May 2024 18:30:25 GMT, Kevin Rushforth wrote: >> maybe >> https://stackoverflow.com/questions/26115139/junit-ignore-or-skip-entire-test-class >> ? > > We still want to use `assumeTrue` as the pattern (for flexibility), so the question is whether there is a better place besides a method annotated with `@BeforeAll` to put it (which also means duplicating the assumption in the `@AfterAll` method). I'm not aware of one, but maybe someone else is? My source: https://stackoverflow.com/q/30112317/873282, but I did totally forget about `@AfterAll`. I was assuming that that would also have been skipped if the `@BeforeAll` was skipped. ? Think, for users coming from JUnit4, it is better to put the statements in each test method, even though not executed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592921618 From duke at openjdk.org Tue May 7 18:50:05 2024 From: duke at openjdk.org (Christoph) Date: Tue, 7 May 2024 18:50:05 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> Message-ID: <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> On Tue, 7 May 2024 18:46:26 GMT, Oliver Kopp wrote: >> We still want to use `assumeTrue` as the pattern (for flexibility), so the question is whether there is a better place besides a method annotated with `@BeforeAll` to put it (which also means duplicating the assumption in the `@AfterAll` method). I'm not aware of one, but maybe someone else is? > > My source: https://stackoverflow.com/q/30112317/873282, but I did totally forget about `@AfterAll`. I was assuming that that would also have been skipped if the `@BeforeAll` was skipped. ? > > Think, for users coming from JUnit4, it is better to put the statements in each test method, even though not executed. Junit 5 has an EnabledOnOs annotation https://junit.org/junit5/docs/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592922258 From angorya at openjdk.org Tue May 7 18:53:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 18:53:04 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: Message-ID: <74q_c3eOpudcQijWx1RdqHF7VTkjuea9xEDzndJjmGI=.607fdff9-cfc2-43c8-be50-d00d01675764@github.com> On Thu, 2 May 2024 23:35:12 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Streamline WinTextRangeProviderTest > > Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 please do not integrate before tests are fixed... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2099092721 From angorya at openjdk.org Tue May 7 18:55:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 18:55:59 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> Message-ID: <42HOiWnpKBiyefBWamtanZh93fSIWIi_z101FqnqlHU=.78ba9816-e1fc-4228-a41a-4596668d0d95@github.com> On Tue, 7 May 2024 18:47:04 GMT, Christoph wrote: > EnabledOnOs thank you @Siedlerchr for this info. I wonder what criteria are set for determining the OS value, and do they match jfx ones? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592928523 From jhendrikx at openjdk.org Tue May 7 19:12:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 7 May 2024 19:12:01 GMT Subject: Integrated: 8331616: ChangeListener is not triggered when the InvalidationListener is removed In-Reply-To: References: Message-ID: On Fri, 3 May 2024 14:45:24 GMT, John Hendrikx wrote: > This PR provides a fix for the linked issue. > > The issue was that when an invalidation listener is removed, and the `ExpressionHelper` type changes from `Generic` to `SingleChange` that it would copy the current value of the `Generic` instance before it was updated (this is because invalidation listeners trigger before change listeners and the current value would only be updated **after** invalidation listeners notifications were completed). > > The code now will update the current value before sending out any notifications **if** there are change listeners present to head off this problem. > > Added a few test cases to verify this. > > Note: the PR which replaces `ExpressionHelper` does not have this problem: https://github.com/openjdk/jfx/pull/1081 This pull request has now been integrated. Changeset: 35880cec Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/35880cec5a998598c64eecbc7b3ae56b6ee3a6d8 Stats: 69 lines in 2 files changed: 66 ins; 2 del; 1 mod 8331616: ChangeListener is not triggered when the InvalidationListener is removed Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1448 From duke at openjdk.org Tue May 7 19:16:02 2024 From: duke at openjdk.org (Christoph) Date: Tue, 7 May 2024 19:16:02 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <42HOiWnpKBiyefBWamtanZh93fSIWIi_z101FqnqlHU=.78ba9816-e1fc-4228-a41a-4596668d0d95@github.com> References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> <42HOiWnpKBiyefBWamtanZh93fSIWIi_z101FqnqlHU=.78ba9816-e1fc-4228-a41a-4596668d0d95@github.com> Message-ID: On Tue, 7 May 2024 18:53:17 GMT, Andy Goryachev wrote: >> Junit 5 has an EnabledOnOs annotation https://junit.org/junit5/docs/5.2.0/api/org/junit/jupiter/api/condition/EnabledOnOs.html > >> EnabledOnOs > > thank you @Siedlerchr for this info. > I wonder what criteria are set for determining the OS value, and do they match jfx ones? They just read the `os.name` with `System.getProperty("os.name")` https://github.com/junit-team/junit5/blob/db47616ab4ccf38ff63e8bff41050d5102c9ff15/junit-jupiter-api/src/main/java/org/junit/jupiter/api/condition/OS.java#L110 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592948514 From angorya at openjdk.org Tue May 7 19:29:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 19:29:02 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> <42HOiWnpKBiyefBWamtanZh93fSIWIi_z101FqnqlHU=.78ba9816-e1fc-4228-a41a-4596668d0d95@github.com> Message-ID: On Tue, 7 May 2024 19:13:02 GMT, Christoph wrote: >>> EnabledOnOs >> >> thank you @Siedlerchr for this info. >> I wonder what criteria are set for determining the OS value, and do they match jfx ones? > > They just read the `os.name` with `System.getProperty("os.name") but that only includes the Standard values. > https://github.com/junit-team/junit5/blob/db47616ab4ccf38ff63e8bff41050d5102c9ff15/junit-jupiter-api/src/main/java/org/junit/jupiter/api/condition/OS.java#L110 > > This only includes the standard OS values. However, an alternative could be to use `@EnabledIf("isWindows")` with a method of that name that returns a boolean > > > boolean isWindows() { > return PlatformUtil.isWindows() > } the logic **is** different, but both variants should be ok for testing purposes. for example, junit: mac = toLowercase(ENGLISH).contains("mac") jfx: mac = startsWith("Mac") ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592960781 From kcr at openjdk.org Tue May 7 19:47:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 19:47:00 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: References: <7eoljDrHQxe4HNQDWkoOBRcqOYWOAvtjmxFYxf0ST64=.ea9ace9f-ddfd-48f1-b72b-bd4272010515@github.com> <7oAhBXXTb6wzIlM_y2fM124Q-A6jAVqS3j2WCg500EA=.abb90353-7866-4e31-80ef-289f997acd7a@github.com> <_85mSCZ5Bmw7-b1W--xv16GE0b6cdUseVYE75T0ffWs=.1cd7afbe-9118-47ed-81ef-b26f0af9434a@github.com> <42HOiWnpKBiyefBWamtanZh93fSIWIi_z101FqnqlHU=.78ba9816-e1fc-4228-a41a-4596668d0d95@github.com> Message-ID: On Tue, 7 May 2024 19:25:53 GMT, Andy Goryachev wrote: >> They just read the `os.name` with `System.getProperty("os.name") but that only includes the Standard values. >> https://github.com/junit-team/junit5/blob/db47616ab4ccf38ff63e8bff41050d5102c9ff15/junit-jupiter-api/src/main/java/org/junit/jupiter/api/condition/OS.java#L110 >> >> This only includes the standard OS values. However, an alternative could be to use `@EnabledIf("isWindows")` with a method of that name that returns a boolean >> >> >> boolean isWindows() { >> return PlatformUtil.isWindows() >> } > > the logic **is** different, but both variants should be ok for testing purposes. > > for example, > junit: mac = toLowercase(ENGLISH).contains("mac") > jfx: mac = startsWith("Mac") I prefer to stick with assumptions since that's what we use everywhere else. Also, it gives us more control. So while we _could_ do something else in the future, this PR isn't the place to do it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1592978053 From duke at openjdk.org Tue May 7 20:25:12 2024 From: duke at openjdk.org (Oliver Kopp) Date: Tue, 7 May 2024 20:25:12 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v27] In-Reply-To: References: Message-ID: <4HAJ_BW2Dz3rouy2fhjwBUdmMlprzZ107kFtOav6heQ=.a621028a-28af-419b-8a1e-e32eca270b3f@github.com> > Fixes https://bugs.openjdk.org/browse/JDK-8330462. > > If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: More "assumeTrue" statements ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1442/files - new: https://git.openjdk.org/jfx/pull/1442/files/d03bdd40..a7436f22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=26 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=25-26 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1442.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442 PR: https://git.openjdk.org/jfx/pull/1442 From duke at openjdk.org Tue May 7 20:39:13 2024 From: duke at openjdk.org (Oliver Kopp) Date: Tue, 7 May 2024 20:39:13 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v28] In-Reply-To: References: Message-ID: > Fixes https://bugs.openjdk.org/browse/JDK-8330462. > > If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1442/files - new: https://git.openjdk.org/jfx/pull/1442/files/a7436f22..603eb7de Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=27 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=26-27 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1442.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442 PR: https://git.openjdk.org/jfx/pull/1442 From kcr at openjdk.org Tue May 7 20:40:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 20:40:08 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> Message-ID: <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> On Fri, 26 Apr 2024 23:36:26 GMT, Alexander Matveev wrote: >> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. >> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): >> - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. >> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. >> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. >> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. >> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. >> - Fixed and improved debug output in Linux AV plugins. >> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. >> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. >> - Removed dead code from MediaManager. >> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] Testing looks good on all three platforms. I verified that HLS streams that use `EXT-X-MEDIA` tag for separate audio channel works (before the fix, it didn't on Windows and Linux). I left one comment on the multiple top-level classes in `HLSConnectionHolder`, and I still need to review the changes in that class, but will wait until you address the feedback I left. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 58: > 56: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.HLS_VALUE_MIMETYPE_MP3; > 57: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.HLS_VALUE_MIMETYPE_UNKNOWN; > 58: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.stripParameters; If you make the other classes in this file nested static classes, then you won't need these static imports. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 480: > 478: } > 479: > 480: class PlaylistLoader extends Thread { Having multiple top-level classes in the same source file is an anti-pattern. Is there a good reason that these can't be nested static classes? If not, then please make this change. You might be able to then make the nested classes private, although there is no harm in leaving them package scope. ------------- PR Review: https://git.openjdk.org/jfx/pull/1435#pullrequestreview-2044045296 PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1592990614 PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1592989352 From kcr at openjdk.org Tue May 7 22:26:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 7 May 2024 22:26:01 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v28] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 20:39:13 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Update full name Looks good. I confirm that the test passes on Windows and is skipped on macOS. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2044294496 From angorya at openjdk.org Tue May 7 23:06:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 7 May 2024 23:06:03 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v28] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 20:39:13 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Update full name LGTM ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2044335247 From arapte at openjdk.org Wed May 8 00:45:03 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 8 May 2024 00:45:03 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v28] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 20:39:13 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8330462. >> >> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Update full name Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2044426549 From almatvee at openjdk.org Wed May 8 02:33:58 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 02:33:58 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> Message-ID: On Tue, 7 May 2024 19:53:57 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] > > modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 480: > >> 478: } >> 479: >> 480: class PlaylistLoader extends Thread { > > Having multiple top-level classes in the same source file is an anti-pattern. Is there a good reason that these can't be nested static classes? If not, then please make this change. You might be able to then make the nested classes private, although there is no harm in leaving them package scope. When these classes were nested classes I got issues with second instance of HLSConnectionHolder. If I remember correctly nested classes of second instance of HLSConnectionHolder were using fields of first HLSConnectionHolder instance. Maybe because I initiated second instance incorrectly. To avoid any such potential issues I decided to move away from nested classes. I would prefer to keep as is or better to move all nested classes under separate package (com.sun.media.jfxmedia.locator.hls). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1593304476 From arapte at openjdk.org Wed May 8 11:17:02 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 8 May 2024 11:17:02 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> Message-ID: On Fri, 26 Apr 2024 23:36:26 GMT, Alexander Matveev wrote: >> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. >> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): >> - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. >> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. >> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. >> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. >> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. >> - Fixed and improved debug output in Linux AV plugins. >> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. >> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. >> - Removed dead code from MediaManager. >> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 123: > 121: "(Lcom/sun/media/jfxmedia/locator/ConnectionHolder;)Lcom/sun/media/jfxmedia/locator/ConnectionHolder;"); > 122: env->DeleteLocalRef(klass); > 123: if (javaEnv.reportException() || (GetAudioStreamConnectionHolder == NULL)) Observed a build warning (MacOS): warning: comparison of function 'GetAudioStreamConnectionHolder' equal to a null pointer is always false [-Wtautological-pointer-compare] ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1593426841 From kcr at openjdk.org Wed May 8 12:26:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 May 2024 12:26:03 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v25] In-Reply-To: <8-WqOmqsAhh4cySHSkJNbz75O7dkZNCKT_bzw16KUHg=.1364c17a-9553-428e-a871-988353845030@github.com> References: <8-WqOmqsAhh4cySHSkJNbz75O7dkZNCKT_bzw16KUHg=.1364c17a-9553-428e-a871-988353845030@github.com> Message-ID: On Thu, 2 May 2024 23:32:19 GMT, Oliver Kopp wrote: >> The fix looks good, I have few comments about the test. >> 1. The test does not compile without fix, hence it won't fail without fix as we are only testing the newly added helper method. >> 2. It is not required to change the error stream, as the test does/need not inspect the error output. >> 3. The test method and parameter source method names can be changed a little. >> 4. We should use the Util class for standard setup like initializing JavaFX/ shutting it down. >> >> >> I tried above changes to test locally, attaching the file for ease. >> [WinTextRangeProviderTest.zip](https://github.com/openjdk/jfx/files/15186626/WinTextRangeProviderTest.zip) > >> 1. The test does not compile without fix, hence it won't fail without fix as we are only testing the newly added helper method. > > Yes, we could not build on existing a11y test. > >> 2. It is not required to change the error stream, as the test does/need not inspect the error output. > > Nice! > >> 3. The test method and parameter source method names can be changed a little. > > Note that `@MethodSoruce` can be used without any parameter - then the same name is used. OK, this is not the style of JFX. > > For JUnit5, the `test` prefix is not necessary any more (and can be removed - see https://docs.openrewrite.org/recipes/java/testing/cleanup/removetestprefix), but I think, because of consistency, it is kept. > >> 4. We should use the Util class for standard setup like initializing JavaFX/ shutting it down. > > Nice! > >> I tried above changes to test locally, attaching the file for ease. [WinTextRangeProviderTest.zip](https://github.com/openjdk/jfx/files/15186626/WinTextRangeProviderTest.zip) > > Thank you. I committed at d03bdd40a3340bd85397f (with you as author, hope this is in line with the policies?!). @koppor This is now ready for you to `/integrate`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2100457469 From kcr at openjdk.org Wed May 8 12:28:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 May 2024 12:28:58 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> Message-ID: On Wed, 8 May 2024 06:00:30 GMT, Ambarish Rapte wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] > > modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 123: > >> 121: "(Lcom/sun/media/jfxmedia/locator/ConnectionHolder;)Lcom/sun/media/jfxmedia/locator/ConnectionHolder;"); >> 122: env->DeleteLocalRef(klass); >> 123: if (javaEnv.reportException() || (GetAudioStreamConnectionHolder == NULL)) > > Observed a build warning (MacOS): > > warning: comparison of function 'GetAudioStreamConnectionHolder' equal to a null pointer is always false [-Wtautological-pointer-compare] Good catch. That looks like a typo to me, and should probably be `mid_GetAudioStreamConnectionHolder == null` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1593947105 From kcr at openjdk.org Wed May 8 12:41:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 May 2024 12:41:59 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> Message-ID: On Wed, 8 May 2024 02:31:08 GMT, Alexander Matveev wrote: >> modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 480: >> >>> 478: } >>> 479: >>> 480: class PlaylistLoader extends Thread { >> >> Having multiple top-level classes in the same source file is an anti-pattern. Is there a good reason that these can't be nested static classes? If not, then please make this change. You might be able to then make the nested classes private, although there is no harm in leaving them package scope. > > When these classes were nested classes I got issues with second instance of HLSConnectionHolder. If I remember correctly nested classes of second instance of HLSConnectionHolder were using fields of first HLSConnectionHolder instance. Maybe because I initiated second instance incorrectly. To avoid any such potential issues I decided to move away from nested classes. I would prefer to keep as is or better to move all nested classes under separate package (com.sun.media.jfxmedia.locator.hls). Did you declare them as `static` (nested) classes? If not, then yes, they will have the behavior you mentioned. A non-static "inner" class exists within an instance of the outer class. A static "nested" class does not. Other than scoping, a nested class behaves like a top-level class. If you do want to keep them as separate top-level classes, then please move each to its own file. I would not recommend creating a new package, though, since that will involve more changes to make the classes and elements you need public. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1593963759 From duke at openjdk.org Wed May 8 12:51:04 2024 From: duke at openjdk.org (Oliver Kopp) Date: Wed, 8 May 2024 12:51:04 GMT Subject: Integrated: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Thu, 18 Apr 2024 12:01:52 GMT, Oliver Kopp wrote: > Fixes https://bugs.openjdk.org/browse/JDK-8330462. > > If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`. This pull request has now been integrated. Changeset: d3da033a Author: Oliver Kopp Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/d3da033a2dd5c287733545935242a8d1f71c0554 Stats: 147 lines in 5 files changed: 142 ins; 0 del; 5 mod 8330462: StringIndexOutOfBoundException when typing anything into TextField Reviewed-by: angorya, kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1442 From duke at openjdk.org Wed May 8 13:59:03 2024 From: duke at openjdk.org (Oliver Kopp) Date: Wed, 8 May 2024 13:59:03 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <2CZH-_xws9Mh9aKWHS5WPG-QtINWabtfcJKFEWU6C4s=.6a347edc-858c-4d82-8933-e3cb75bfbbe2@github.com> References: <2CZH-_xws9Mh9aKWHS5WPG-QtINWabtfcJKFEWU6C4s=.6a347edc-858c-4d82-8933-e3cb75bfbbe2@github.com> Message-ID: <-4V6H-bXywUelnzYy1nEyM-pMpZb7zO17hAlOJ93Xd4=.28d71d00-ffb2-4c9c-a186-2386e0311fc6@github.com> On Tue, 7 May 2024 06:32:58 GMT, Ambarish Rapte wrote: >> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: >> >> Streamline WinTextRangeProviderTest >> >> Source: https://github.com/openjdk/jfx/pull/1442#pullrequestreview-2035329983 > >>Thank you. I committed at https://github.com/openjdk/jfx/commit/d03bdd40a3340bd85397fe2ceaa7f053a58da6c5 (with you as author, hope this is in line with the policies?!). > > Thanks @koppor, the fix looks good. > That's a great gesture, thanks, but I was just reviewing the changes, you don't have to add me as a contributor. > Thanks for your contribution, Approving.! @arapte @andy-goryachev-oracle @kevinrushforth Thank you for your ongoing support, deep analysis (both the issue and the algorithms needed), and code pointers and guidance. Looking forward to the next JavaFX release where this fix is included! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2100639593 From angorya at openjdk.org Wed May 8 14:23:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 May 2024 14:23:03 GMT Subject: Integrated: 8092102: Labeled: textTruncated property In-Reply-To: References: Message-ID: <8eFT6jaWFiy-h2cvQ2KDy1ITVKSZI0EG6GKTDAtQCvk=.7632c648-5bbd-4713-841b-9f215b604a6a@github.com> On Mon, 4 Mar 2024 21:04:28 GMT, Andy Goryachev wrote: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property is being set by the code which computes the actual text string to be displayed (and which inserts the ellipsis string) in `LabeledSkinBase.updateDisplayedText(double,double)`. > > > **Alternative** > > None exists as this requires changes to the core (Utils). > > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) This pull request has now been integrated. Changeset: 7699c448 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/7699c448bbdfe4213f74eb47409d9c42b16b59a4 Stats: 396 lines in 7 files changed: 337 ins; 28 del; 31 mod 8092102: Labeled: textTruncated property Reviewed-by: kpk, kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Wed May 8 14:30:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 May 2024 14:30:07 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <-4V6H-bXywUelnzYy1nEyM-pMpZb7zO17hAlOJ93Xd4=.28d71d00-ffb2-4c9c-a186-2386e0311fc6@github.com> References: <2CZH-_xws9Mh9aKWHS5WPG-QtINWabtfcJKFEWU6C4s=.6a347edc-858c-4d82-8933-e3cb75bfbbe2@github.com> <-4V6H-bXywUelnzYy1nEyM-pMpZb7zO17hAlOJ93Xd4=.28d71d00-ffb2-4c9c-a186-2386e0311fc6@github.com> Message-ID: On Wed, 8 May 2024 13:56:43 GMT, Oliver Kopp wrote: >>>Thank you. I committed at https://github.com/openjdk/jfx/commit/d03bdd40a3340bd85397fe2ceaa7f053a58da6c5 (with you as author, hope this is in line with the policies?!). >> >> Thanks @koppor, the fix looks good. >> That's a great gesture, thanks, but I was just reviewing the changes, you don't have to add me as a contributor. >> Thanks for your contribution, Approving.! > > @arapte @andy-goryachev-oracle @kevinrushforth Thank you for your ongoing support, deep analysis (both the issue and the algorithms needed), and code pointers and guidance. Looking forward to the next JavaFX release where this fix is included! Thank you @koppor for fixing the issue! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2100716412 From kcr at openjdk.org Wed May 8 14:34:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 May 2024 14:34:05 GMT Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v26] In-Reply-To: <-4V6H-bXywUelnzYy1nEyM-pMpZb7zO17hAlOJ93Xd4=.28d71d00-ffb2-4c9c-a186-2386e0311fc6@github.com> References: <2CZH-_xws9Mh9aKWHS5WPG-QtINWabtfcJKFEWU6C4s=.6a347edc-858c-4d82-8933-e3cb75bfbbe2@github.com> <-4V6H-bXywUelnzYy1nEyM-pMpZb7zO17hAlOJ93Xd4=.28d71d00-ffb2-4c9c-a186-2386e0311fc6@github.com> Message-ID: On Wed, 8 May 2024 13:56:43 GMT, Oliver Kopp wrote: > Looking forward to the next JavaFX release where this fix is included! It should be available in the next EA build of JavaFX 23. @arapte will backport it to jfx22u for JavaFX 22.0.2. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2100726731 From angorya at openjdk.org Wed May 8 17:30:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 8 May 2024 17:30:59 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2] In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev wrote: >> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). > > 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 two additional commits since the last revision: > > - Merge branch 'master' into 8330590.prev.word > - 8330590 TextInputControl: previous word fails with Bhojpuri characters I've created https://bugs.openjdk.org/browse/JDK-8331951 to deal with the "next word" function issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2101065810 From kevin.rushforth at oracle.com Wed May 8 18:31:26 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 8 May 2024 11:31:26 -0700 Subject: Proposed schedule for JavaFX 23 Message-ID: Here is the proposed schedule for JavaFX 23. RDP1: Jul 11, 2024 (aka ?feature freeze?) RDP2: Aug 1, 2024 Freeze: Aug 29, 2024 GA: Sep 17, 2024 We plan to fork a jfx23 stabilization branch at RDP1. The start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From almatvee at openjdk.org Wed May 8 22:02:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 22:02:21 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v4] In-Reply-To: References: Message-ID: > - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. > - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): > - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. > - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. > - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. > - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. > - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. > - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. > - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. > - Fixed and improved debug output in Linux AV plugins. > - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. > - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. > - Removed dead code from MediaManager. > - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v3] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1435/files - new: https://git.openjdk.org/jfx/pull/1435/files/84103bd4..4e2e1572 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1435&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1435&range=02-03 Stats: 1198 lines in 2 files changed: 284 ins; 296 del; 618 mod Patch: https://git.openjdk.org/jfx/pull/1435.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1435/head:pull/1435 PR: https://git.openjdk.org/jfx/pull/1435 From almatvee at openjdk.org Wed May 8 22:02:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 22:02:21 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> Message-ID: On Fri, 26 Apr 2024 23:36:26 GMT, Alexander Matveev wrote: >> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. >> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): >> - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. >> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. >> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. >> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. >> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. >> - Fixed and improved debug output in Linux AV plugins. >> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. >> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. >> - Removed dead code from MediaManager. >> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v3] - Fixed NULL check in Locator. - Declared HLSConnectionHolder helper classes and static nested classes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1435#issuecomment-2101574260 From almatvee at openjdk.org Wed May 8 22:02:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 22:02:21 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> Message-ID: On Tue, 7 May 2024 19:54:52 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2] > > modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java line 58: > >> 56: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.HLS_VALUE_MIMETYPE_MP3; >> 57: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.HLS_VALUE_MIMETYPE_UNKNOWN; >> 58: import static com.sun.media.jfxmedia.locator.HLSConnectionHolder.stripParameters; > > If you make the other classes in this file nested static classes, then you won't need these static imports. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1594747872 From almatvee at openjdk.org Wed May 8 22:02:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 22:02:21 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> <6V35P0kn_ixtgaDESNaELmVXsZGqgjIg86WSS_X-Z9c=.330cbb4d-c365-4ea0-89f7-e5f09e098883@github.com> Message-ID: On Wed, 8 May 2024 12:39:24 GMT, Kevin Rushforth wrote: >> When these classes were nested classes I got issues with second instance of HLSConnectionHolder. If I remember correctly nested classes of second instance of HLSConnectionHolder were using fields of first HLSConnectionHolder instance. Maybe because I initiated second instance incorrectly. To avoid any such potential issues I decided to move away from nested classes. I would prefer to keep as is or better to move all nested classes under separate package (com.sun.media.jfxmedia.locator.hls). > > Did you declare them as `static` (nested) classes? If not, then yes, they will have the behavior you mentioned. A non-static "inner" class exists within an instance of the outer class. A static "nested" class does not. Other than scoping, a nested class behaves like a top-level class. > > If you do want to keep them as separate top-level classes, then please move each to its own file. I would not recommend creating a new package, though, since that will involve more changes to make the classes and elements you need public. No, I did not declared them as `static`. Fixed by declaring these classes as nested static classes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1594747723 From almatvee at openjdk.org Wed May 8 22:02:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 May 2024 22:02:21 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v3] In-Reply-To: References: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com> Message-ID: On Wed, 8 May 2024 12:26:06 GMT, Kevin Rushforth wrote: >> modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 123: >> >>> 121: "(Lcom/sun/media/jfxmedia/locator/ConnectionHolder;)Lcom/sun/media/jfxmedia/locator/ConnectionHolder;"); >>> 122: env->DeleteLocalRef(klass); >>> 123: if (javaEnv.reportException() || (GetAudioStreamConnectionHolder == NULL)) >> >> Observed a build warning (MacOS): >> >> warning: comparison of function 'GetAudioStreamConnectionHolder' equal to a null pointer is always false [-Wtautological-pointer-compare] > > Good catch. That looks like a typo to me, and should probably be `mid_GetAudioStreamConnectionHolder == null` Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1435#discussion_r1594743714 From duke at openjdk.org Thu May 9 06:50:00 2024 From: duke at openjdk.org (duke) Date: Thu, 9 May 2024 06:50:00 GMT Subject: Withdrawn: 8299423: JavaFX Mac system menubar leaks In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 13:32:32 GMT, Florian Kirmaier wrote: > Based on my previous PR: https://github.com/openjdk/jfx/pull/987 > This one only contains the test. > Because it was fixed in some other PR. > But i would like to see the Test being merged, to ensure it never breaks again. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1401 From arapte at openjdk.org Thu May 9 07:49:57 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 9 May 2024 07:49:57 GMT Subject: RFR: 8328603: HLS video stream fails to render consistently In-Reply-To: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com> References: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com> Message-ID: <3Gofj59As9wIZO42PS-MVIduY063dAKvs0NGotHIeCg=.f53f74dc-f4fa-474c-8c55-3b2099476df7@github.com> On Sat, 13 Apr 2024 01:36:01 GMT, Alexander Matveev wrote: > - When video fails to render AVFoundation outputs frame in `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` format which is not supported. We do force format change after that to `kCVPixelFormatType_422YpCbCr8`, but AVFoundation does not provides any video frames after format change. Not sure why it happens. > - When video worked for stream in this issue, then AVFoundation was using `kCVPixelFormatType_422YpCbCr8` for some reason instead of `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange`. > - I tested format fallback from `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` to `kCVPixelFormatType_422YpCbCr8` manually and many streams I tried works fine, except one reported in this bug. > - If AVFoundation is initialized with list of formats JavaFX Media rendering supports, then this issue is no longer reproducible. > - Fixed by providing list of supported formats to AVFoundation. > - Removed unused variable `response`. > - Tested with all streams I have and no issues found. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1440#pullrequestreview-2047354456 From jvos at openjdk.org Thu May 9 09:08:02 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 May 2024 09:08:02 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: On Tue, 7 May 2024 09:39:23 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Use viewport length as block increment modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1808: > 1806: * @return the value in pixels > 1807: */ > 1808: public double getBlockIncrement() { I'd rather not add that method but instead make `getViewportLength()` public. That would benefit other use cases, and it is more behavior-agnostic. The "viewportLength" is easier to define in a contract than a "blockIncrement" and since this is exactly what you return, it sounds like a reasonable thing to do. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595180937 From kpk at openjdk.org Thu May 9 09:38:31 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 9 May 2024 09:38:31 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll [v2] In-Reply-To: References: Message-ID: > The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the items. Fixed the issue by restoring the selection in this case. > > Added a unit test to validate the fix. > [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) is also fixed with this change and added a unit test for the same. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix JDK-8279139 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1452/files - new: https://git.openjdk.org/jfx/pull/1452/files/0f362fd7..f1582a2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1452&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1452&range=00-01 Stats: 41 lines in 2 files changed: 33 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1452.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1452/head:pull/1452 PR: https://git.openjdk.org/jfx/pull/1452 From fkirmaier at openjdk.org Thu May 9 10:01:34 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 9 May 2024 10:01:34 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v5] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Mage getViewportLength() public and use it instead of getBlockIncrement() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/3972d8ad..b08aaa59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=03-04 Stats: 37 lines in 4 files changed: 8 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From duke at openjdk.org Thu May 9 10:01:35 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 9 May 2024 10:01:35 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v4] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 09:04:54 GMT, Johan Vos wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Use viewport length as block increment > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1808: > >> 1806: * @return the value in pixels >> 1807: */ >> 1808: public double getBlockIncrement() { > > I'd rather not add that method but instead make `getViewportLength()` public. That would benefit other use cases, and it is more behavior-agnostic. The "viewportLength" is easier to define in a contract than a "blockIncrement" and since this is exactly what you return, it sounds like a reasonable thing to do. Good suggestion. I have made the necessary changes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595238708 From kcr at openjdk.org Thu May 9 11:47:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 May 2024 11:47:58 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v4] In-Reply-To: References: Message-ID: On Wed, 8 May 2024 22:02:21 GMT, Alexander Matveev wrote: >> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. >> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): >> - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. >> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. >> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. >> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. >> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. >> - Fixed and improved debug output in Linux AV plugins. >> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. >> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. >> - Removed dead code from MediaManager. >> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v3] Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1435#pullrequestreview-2047771222 From arapte at openjdk.org Thu May 9 12:37:58 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 9 May 2024 12:37:58 GMT Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming [v4] In-Reply-To: References: Message-ID: On Wed, 8 May 2024 22:02:21 GMT, Alexander Matveev wrote: >> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. >> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): >> - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. >> - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. >> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. >> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. >> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. >> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. >> - Fixed and improved debug output in Linux AV plugins. >> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. >> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. >> - Removed dead code from MediaManager. >> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v3] Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1435#pullrequestreview-2047852388 From kcr at openjdk.org Thu May 9 14:40:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 May 2024 14:40:03 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v5] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 10:01:34 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Mage getViewportLength() public and use it instead of getBlockIncrement() @eduardsdv I left a couple comments on the API docs for the new public method. Regarding the CSR, if you don't have a JBS account, perhaps you can ask @FlorianKirmaier or @johanvos to create the CSR for you. And I agree with @andy-goryachev-oracle that you should be added a contributor. @FlorianKirmaier will need to do that, since only the author of the PR can add contributors. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1915: > 1913: > 1914: /** > 1915: * The length of the viewport portion of the VirtualFlow as computed during the layout pass. Suggestion: use code case, `{@code VirtualFlow}` modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1919: > 1917: * but it does not necessarily have to be the same value. > 1918: * > 1919: * @return the viewport length in pixel That should be "in pixels" (plural). Also, please add an `@since 23` tag after the return tag. ------------- PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2048102268 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595534529 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595535571 From fkirmaier at openjdk.org Thu May 9 14:49:26 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 9 May 2024 14:49:26 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Adjust javadoc of the getViewportLength() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/b08aaa59..645feee3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=04-05 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From duke at openjdk.org Thu May 9 14:49:26 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 9 May 2024 14:49:26 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: <8ZA4U3wL8GIoa5Cg06kO_AEi5cNYCPigeofGLpzO0eE=.47601f86-18a8-4a24-9c0e-76b4f0e45176@github.com> On Wed, 13 Mar 2024 08:55:14 GMT, Florian Kirmaier wrote: >> @FlorianKirmaier I still think this would be a good addition. I believe there is only one open question (from Marius) so it would be great if you can answer that. > > @johanvos > Great to see you would like to see it merged! > I've worked on this topic together with @eduardsdv , > So consider his response to be my answer to the question. I ask @FlorianKirmaier to create a CSR ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2102809583 From duke at openjdk.org Thu May 9 14:49:26 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 9 May 2024 14:49:26 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v5] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 14:31:56 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Mage getViewportLength() public and use it instead of getBlockIncrement() > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1915: > >> 1913: >> 1914: /** >> 1915: * The length of the viewport portion of the VirtualFlow as computed during the layout pass. > > Suggestion: use code case, `{@code VirtualFlow}` Done. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1919: > >> 1917: * but it does not necessarily have to be the same value. >> 1918: * >> 1919: * @return the viewport length in pixel > > That should be "in pixels" (plural). > > Also, please add an `@since 23` tag after the return tag. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595550376 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1595550482 From pavelturk2000 at gmail.com Thu May 9 14:56:12 2024 From: pavelturk2000 at gmail.com (PavelTurk) Date: Thu, 9 May 2024 17:56:12 +0300 Subject: There is no workaround for JDK-8324327 Message-ID: <325b046b-f720-d150-3283-9886da63a172@gmail.com> Hello all. This is about https://bugs.openjdk.org/browse/JDK-8324327 . Andy Goryachev wrote in comment "Change to the default constructor and the issue disappears". I don't see that using default constructor solves the problem. I tried the following code : public class JavaFxTest7 extends Application { ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage primaryStage) { ??????? VBox root = new VBox(); ??????? ColorPicker picker = new ColorPicker(); ??????? root.getChildren().addAll(picker); ??????? var scene = new Scene(root, 400, 300); ??????? primaryStage.setScene(scene); ??????? primaryStage.show(); ??? } } and I have the same bug. JavaFX: 23-ea+3 Java: 21.0.2 OS: Ubuntu 20.04.3 LTS So, ColorPicker is always broken. Best regards, Pavel From andy.goryachev at oracle.com Thu May 9 15:18:03 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 9 May 2024 15:18:03 +0000 Subject: There is no workaround for JDK-8324327 In-Reply-To: <325b046b-f720-d150-3283-9886da63a172@gmail.com> References: <325b046b-f720-d150-3283-9886da63a172@gmail.com> Message-ID: Perhaps I should have left a clearer note. The bug is still there, no one worked on it yet. Changing to the default constructor at least works as expected - the large white square (selected color) appears over the right spot. In the original example, the Color.CORAL is apparently not a part of the palette, so instead the white (incorrect) square appears at the wrong place. Change the constructor argument to a color which is present in the palette and it would work as expected. This is just a workaround, the bug is still there. -andy From: openjfx-dev on behalf of PavelTurk Date: Thursday, May 9, 2024 at 07:56 To: openjfx-dev at openjdk.org Subject: There is no workaround for JDK-8324327 Hello all. This is about https://bugs.openjdk.org/browse/JDK-8324327 . Andy Goryachev wrote in comment "Change to the default constructor and the issue disappears". I don't see that using default constructor solves the problem. I tried the following code : public class JavaFxTest7 extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { VBox root = new VBox(); ColorPicker picker = new ColorPicker(); root.getChildren().addAll(picker); var scene = new Scene(root, 400, 300); primaryStage.setScene(scene); primaryStage.show(); } } and I have the same bug. JavaFX: 23-ea+3 Java: 21.0.2 OS: Ubuntu 20.04.3 LTS So, ColorPicker is always broken. Best regards, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavelturk2000 at gmail.com Thu May 9 16:18:11 2024 From: pavelturk2000 at gmail.com (PavelTurk) Date: Thu, 9 May 2024 19:18:11 +0300 Subject: There is no workaround for JDK-8324327 In-Reply-To: References: <325b046b-f720-d150-3283-9886da63a172@gmail.com> Message-ID: <5d22f339-f2a6-4af2-8f95-c18f6a9fa62d@gmail.com> Thank you for your answer and explanation. As I understand the problem is not in using the type of the consructor, but in the initial color (from palette or not): ??????? ColorPicker picker = new ColorPicker(); ??????? picker.setValue(Color.YELLOW);//this works OK, the color from palette ??????? picker.setValue(Color.CORAL);//this doesn't work, the color not from palette Best regards, Pavel On 5/9/24 6:18 PM, Andy Goryachev wrote: > > Perhaps I should have left a clearer note.? The bug is still there, no one worked on it yet. > > Changing to the default constructor at least works as expected - the large white square (selected color) appears over the right spot.? In the original example, the Color.CORAL is apparently not a part of the palette, so instead the white (incorrect) square appears at the wrong place.? Change the constructor argument to a color which is present in the palette and it would work as expected.? This is just a workaround, the bug is still there. > > -andy > > *From: *openjfx-dev on behalf of PavelTurk > *Date: *Thursday, May 9, 2024 at 07:56 > *To: *openjfx-dev at openjdk.org > *Subject: *There is no workaround for JDK-8324327 > > Hello all. > > This is about https://bugs.openjdk.org/browse/JDK-8324327 . > > Andy Goryachev wrote in comment "Change to the default constructor and the issue disappears". > I don't see that using default constructor solves the problem. I tried the following code : > > public class JavaFxTest7 extends Application { > > ???? public static void main(String[] args) { > ???????? launch(args); > ???? } > > ???? @Override > ???? public void start(Stage primaryStage) { > ???????? VBox root = new VBox(); > ???????? ColorPicker picker = new ColorPicker(); > ???????? root.getChildren().addAll(picker); > > ???????? var scene = new Scene(root, 400, 300); > ???????? primaryStage.setScene(scene); > ???????? primaryStage.show(); > ???? } > } > > and I have the same bug. > > JavaFX: 23-ea+3 > Java: 21.0.2 > OS: Ubuntu 20.04.3 LTS > > So, ColorPicker is always broken. > > Best regards, Pavel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Thu May 9 17:37:04 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 May 2024 17:37:04 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 14:49:26 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of the getViewportLength() I did a number of tests with the new approach. It works as expected, and I don't see scenarios that could lead to a performance issue. FWIW, this is a rather drastic change to the behavior, but there are no technical reasons to not do it. There are currently no tests that assert the current behavior, and I didn't find it in the public docs either (the idea about mapping scroll events to the top/bottom of a cell is hinted in the code though). It is very likely that existing application will behave differently after this PR. But I think that is more a UX discussion than a code discussion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2103108966 From angorya at openjdk.org Thu May 9 17:48:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 May 2024 17:48:05 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 17:34:11 GMT, Johan Vos wrote: > the idea about mapping scroll events to the top/bottom of a cell is hinted in the code though could you please point to these places? I think this change is inline with the modern UIs, at least macOS and Windows. As Eduard correctly pointed out, it makes sense to align on the cell top boundary when changing selection, but mouse navigation via scroll bar should use the view port height. In other words, going back and forward with the mouse should revert the control to the same state (unless it hit the rail). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2103136466 From jvos at openjdk.org Thu May 9 18:07:24 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 May 2024 18:07:24 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v14] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into 8319779-systemmenu - Remove whiteline and language error - Ignore test in case the underlying GlassSystemMenu is not supported. - Update modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java Co-authored-by: John Hendrikx - Merge branch 'master' into 8319779-systemmenu - Add additional test for IOOBE detection. This test comes from JDK-8323787 - Revert some of the conditional bindings. Clear menu construction when an menuitem that is a menu needs to be removed Add a test for the latter - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu - Cleanup test - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. Add a test to make sure those references are gone. - ... and 5 more: https://git.openjdk.org/jfx/compare/7699c448...72029efc ------------- Changes: https://git.openjdk.org/jfx/pull/1283/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=13 Stats: 663 lines in 5 files changed: 462 ins; 192 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Thu May 9 18:40:13 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 May 2024 18:40:13 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v15] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add type info Fix issue where notifications are missed when a new property is used. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/72029efc..da94142f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=13-14 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From almatvee at openjdk.org Thu May 9 19:47:03 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 May 2024 19:47:03 GMT Subject: Integrated: 8328603: HLS video stream fails to render consistently In-Reply-To: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com> References: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com> Message-ID: On Sat, 13 Apr 2024 01:36:01 GMT, Alexander Matveev wrote: > - When video fails to render AVFoundation outputs frame in `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` format which is not supported. We do force format change after that to `kCVPixelFormatType_422YpCbCr8`, but AVFoundation does not provides any video frames after format change. Not sure why it happens. > - When video worked for stream in this issue, then AVFoundation was using `kCVPixelFormatType_422YpCbCr8` for some reason instead of `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange`. > - I tested format fallback from `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` to `kCVPixelFormatType_422YpCbCr8` manually and many streams I tried works fine, except one reported in this bug. > - If AVFoundation is initialized with list of formats JavaFX Media rendering supports, then this issue is no longer reproducible. > - Fixed by providing list of supported formats to AVFoundation. > - Removed unused variable `response`. > - Tested with all streams I have and no issues found. This pull request has now been integrated. Changeset: eb6d55f7 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/eb6d55f7f067469e89402da2bfa46e1ecf11ea02 Stats: 19 lines in 1 file changed: 16 ins; 1 del; 2 mod 8328603: HLS video stream fails to render consistently Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1440 From jvos at openjdk.org Thu May 9 19:48:19 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 May 2024 19:48:19 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add more type info ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/da94142f..d7067c16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=14-15 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From almatvee at openjdk.org Thu May 9 21:59:41 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 May 2024 21:59:41 GMT Subject: Integrated: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming In-Reply-To: References: Message-ID: On Tue, 2 Apr 2024 00:18:04 GMT, Alexander Matveev wrote: > - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming. > - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details): > - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. > - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag. > - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag. > - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits. > - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams. > - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend. > - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes. > - Fixed and improved debug output in Linux AV plugins. > - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time. > - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams. > - Removed dead code from MediaManager. > - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases. This pull request has now been integrated. Changeset: b86e6771 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/b86e6771b906bdf7ed517eb2d5ab76a2e92c1282 Stats: 1939 lines in 30 files changed: 1170 ins; 321 del; 448 mod 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1435 From fkirmaier at openjdk.org Fri May 10 09:29:24 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 10 May 2024 09:29:24 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 14:49:26 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of the getViewportLength() I've added eduard as a contributor! **CSR** I've created a CSR. https://bugs.openjdk.org/browse/JDK-8332041 If i remember correctly, the name of the ticket and the CSR must be the same? Otherwise i could change it to something like "JavaFX, add the method double VirtualFlow.getViewportLength()" ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2104269970 From kcr at openjdk.org Fri May 10 12:11:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 May 2024 12:11:00 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Fri, 10 May 2024 09:26:18 GMT, Florian Kirmaier wrote: > I've added eduard as a contributor! > > **CSR** I've created a CSR. https://bugs.openjdk.org/browse/JDK-8332041 Thanks! > If i remember correctly, the name of the ticket and the CSR must be the same? Otherwise i could change it to something like "JavaFX, add the method double VirtualFlow.getViewportLength()" Yes, the titles of the JBS bug, the associated CSR, and the PR must all match. And speaking of the CSR, based on Johan's comment about the behavior change, that should also be documented in the CSR. We don't currently document the behavior of most controls in the spec, but significant behavioral changes should still be listed in the CSR when they change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2104494122 From org.openjdk at io7m.com Sun May 12 10:16:36 2024 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sun, 12 May 2024 10:16:36 +0000 Subject: KeyCode in the javafx.scene.robot.Robot interface Message-ID: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> Hello! I maintain a test harness for JavaFX applications: https://www.github.com/io7m-com/xoanon I expose an interface that uses the javafx.scene.robot.Robot interface internally, but I expose a slightly higher level API that allows for (amongst other things) typing text as strings on components rather than sending individual key codes. The problem I immediately run into is that KeyCodes are keyboard layout specific, and there doesn't appear to be any way to detect what keyboard layout is in use. If I, for example, send the KeyCode for the `@` symbol, I'll actually get `"` on some keyboard layouts. This can cause some types of tests to fail, even though the code is correct. Consider a test where an email address is typed into a text field, and then the form containing the field is checked to see if the text field accepted/rejected the text as being a valid email address. On some keyboard layouts, a test that sends the string "someone at example.com" will fail because what ends up in the text field is actually "someone"example.com". I provide a workaround for this: At the start of the test suite run, xoanon will send every KeyCode to a text field one at a time and see what character appeared in the text field as a result. It then builds a mapping between characters to KeyCodes, and it can then do the translations as necessary when running the rest of the test suite: https://github.com/io7m-com/xoanon?tab=readme-ov-file#keymap-generation Unfortunately, this is still rather flaky. This often seems to fail more or less at random for reasons that aren't clear to me. Is there some way the Robot interface could be extended to allow for typing strings? Failing that, is there some way JavaFX could advertise the underlying keyboard map? I feel like some underlying component must know the information I'm trying to infer, but it doesn't seem to be exposed anywhere that I've been able to find. -- Mark Raynsford | https://www.io7m.com From tsayao at openjdk.org Sun May 12 11:03:36 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 12 May 2024 11:03:36 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v11] In-Reply-To: References: Message-ID: > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Use prismES2EGLX11 as build name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1381/files - new: https://git.openjdk.org/jfx/pull/1381/files/51c35579..47985493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=09-10 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381 From mstrauss at openjdk.org Mon May 13 03:27:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 13 May 2024 03:27:12 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff Looks good to me. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2051622575 From arapte at openjdk.org Mon May 13 09:30:44 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 13 May 2024 09:30:44 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> References: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> Message-ID: On Mon, 6 May 2024 23:14:11 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > vertical scrolling tests Tested a few samples. It looks good. I need sometime (a day or two) to complete code review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2107083705 From arapte at openjdk.org Mon May 13 09:43:05 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 13 May 2024 09:43:05 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField Message-ID: The backport is almost clean. While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. Test passes on windows. ------------- Commit messages: - 8330462: StringIndexOutOfBoundException when typing anything into TextField Changes: https://git.openjdk.org/jfx22u/pull/28/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=28&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330462 Stats: 147 lines in 5 files changed: 142 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx22u/pull/28.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/28/head:pull/28 PR: https://git.openjdk.org/jfx22u/pull/28 From angorya at openjdk.org Mon May 13 14:34:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 May 2024 14:34:40 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v13] In-Reply-To: <2GY47oVE9mCl0FLEyRr8FvMsZVR1z7Jp5K45vCTx668=.463f1350-f524-4e14-87f9-618c2c1b6463@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> <2GY47oVE9mCl0FLEyRr8FvMsZVR1z7Jp5K45vCTx668=.463f1350-f524-4e14-87f9-618c2c1b6463@github.com> Message-ID: On Fri, 12 Apr 2024 22:47:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - 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 > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - tolerance > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - undo merge > - ... and 22 more: https://git.openjdk.org/jfx/compare/44d53baf...197cfaf0 keep alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2107764343 From tsayao at openjdk.org Mon May 13 14:54:42 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 13 May 2024 14:54:42 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v11] In-Reply-To: References: Message-ID: On Sun, 12 May 2024 11:03:36 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Use prismES2EGLX11 as build name I will no longer commit to this change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2107849740 From tsayao at openjdk.org Mon May 13 14:54:43 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 13 May 2024 14:54:43 GMT Subject: Withdrawn: 8329820: [Linux] Prefer EGL over GLX In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 17:54:47 GMT, Thiago Milczarek Sayao wrote: > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1381 From tsayao at openjdk.org Mon May 13 14:54:44 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 13 May 2024 14:54:44 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I will no longer commit to this change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2107846994 From tsayao at openjdk.org Mon May 13 14:54:44 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 13 May 2024 14:54:44 GMT Subject: Withdrawn: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1080 From angorya at openjdk.org Mon May 13 15:16:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 May 2024 15:16:17 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 09:36:39 GMT, Ambarish Rapte wrote: > The backport is almost clean. > While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. > > Test passes on windows. tests/system/src/test/.classpath line 17: > 15: > 16: > 17: I wonder if we should just copy this attribute from the master branch, to avoid future conflicts? ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598647534 From kcr at openjdk.org Mon May 13 15:54:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 May 2024 15:54:33 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 09:36:39 GMT, Ambarish Rapte wrote: > The backport is almost clean. > While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. > > Test passes on windows. LGTM Don't forget to also request maintainer approval (using the Skara command `/approval request REASON FOR THE REQUEST`) ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx22u/pull/28#pullrequestreview-2053086479 From kcr at openjdk.org Mon May 13 15:58:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 May 2024 15:58:05 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 15:13:20 GMT, Andy Goryachev wrote: >> The backport is almost clean. >> While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. >> >> Test passes on windows. > > tests/system/src/test/.classpath line 17: > >> 15: >> 16: >> 17: > > I wonder if we should just copy this attribute from the master branch, to avoid future conflicts? Probably not as part of this backport. Also, the fact that they are different suggests that there might be another fix that is in mainline but not in jfx22u (and we wouldn't choose to backport another fix just to avoid a merge conflict). ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598703396 From angorya at openjdk.org Mon May 13 16:46:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 May 2024 16:46:04 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 09:36:39 GMT, Ambarish Rapte wrote: > The backport is almost clean. > While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. > > Test passes on windows. lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx22u/pull/28#pullrequestreview-2053199548 From angorya at openjdk.org Mon May 13 16:46:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 13 May 2024 16:46:05 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 15:54:47 GMT, Kevin Rushforth wrote: >> tests/system/src/test/.classpath line 17: >> >>> 15: >>> 16: >>> 17: >> >> I wonder if we should just copy this attribute from the master branch, to avoid future conflicts? > > Probably not as part of this backport. Also, the fact that they are different suggests that there might be another fix that is in mainline but not in jfx22u (and we wouldn't choose to backport another fix just to avoid a merge conflict). forgot to mention the diff is just a different ordering. ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598760279 From kcr at openjdk.org Mon May 13 16:46:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 May 2024 16:46:06 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: <_fRU-23gasE8a8gp6bsO7xJGjSUqGG0y_y3u55dkEvI=.133a9d11-905d-47a1-9017-5f3c5240b30d@github.com> On Mon, 13 May 2024 16:39:43 GMT, Andy Goryachev wrote: >> Probably not as part of this backport. Also, the fact that they are different suggests that there might be another fix that is in mainline but not in jfx22u (and we wouldn't choose to backport another fix just to avoid a merge conflict). > > forgot to mention the diff is just a different ordering. Ah, I see. In that case, reordering to match mainline seems good. ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598762875 From arapte at openjdk.org Mon May 13 17:30:02 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 13 May 2024 17:30:02 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: <_fRU-23gasE8a8gp6bsO7xJGjSUqGG0y_y3u55dkEvI=.133a9d11-905d-47a1-9017-5f3c5240b30d@github.com> References: <_fRU-23gasE8a8gp6bsO7xJGjSUqGG0y_y3u55dkEvI=.133a9d11-905d-47a1-9017-5f3c5240b30d@github.com> Message-ID: <3rkOgu3A-OabkwytfNnaTg0TifSQ4T7bXMS_ZNr7DpE=.096ffd7d-00f4-46c8-9d00-651ff3f743f6@github.com> On Mon, 13 May 2024 16:42:05 GMT, Kevin Rushforth wrote: >> forgot to mention the diff is just a different ordering. > > Ah, I see. In that case, reordering to match mainline seems good. May be I am missing something here, I verified the order, it is same as mainline jfx. (jfx has 3 more, that follow the new addition) ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598812144 From kcr at openjdk.org Mon May 13 17:39:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 13 May 2024 17:39:16 GMT Subject: [jfx22u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: <3rkOgu3A-OabkwytfNnaTg0TifSQ4T7bXMS_ZNr7DpE=.096ffd7d-00f4-46c8-9d00-651ff3f743f6@github.com> References: <_fRU-23gasE8a8gp6bsO7xJGjSUqGG0y_y3u55dkEvI=.133a9d11-905d-47a1-9017-5f3c5240b30d@github.com> <3rkOgu3A-OabkwytfNnaTg0TifSQ4T7bXMS_ZNr7DpE=.096ffd7d-00f4-46c8-9d00-651ff3f743f6@github.com> Message-ID: On Mon, 13 May 2024 17:26:02 GMT, Ambarish Rapte wrote: >> Ah, I see. In that case, reordering to match mainline seems good. > > May be I am missing something here, > I verified the order, it is same as mainline jfx. (jfx has 3 more, that follow the new addition) In that case, my earlier comment about not worrying about it for this backport is best. ------------- PR Review Comment: https://git.openjdk.org/jfx22u/pull/28#discussion_r1598821988 From arapte at openjdk.org Mon May 13 17:39:17 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 13 May 2024 17:39:17 GMT Subject: [jfx22u] Integrated: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: References: Message-ID: On Mon, 13 May 2024 09:36:39 GMT, Ambarish Rapte wrote: > The backport is almost clean. > While cherry picking the mainline commit, a minor merge conflict was shown in a the file `tests/system/src/test/.classpath` : The mainline file has a few additional exports compared to 22u. > > Test passes on windows. This pull request has now been integrated. Changeset: 2bfd9f60 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx22u/commit/2bfd9f60d53b93426544e9c9ef2a3e7d6145d1a9 Stats: 147 lines in 5 files changed: 142 ins; 0 del; 5 mod 8330462: StringIndexOutOfBoundException when typing anything into TextField Reviewed-by: kcr, angorya Backport-of: d3da033a2dd5c287733545935242a8d1f71c0554 ------------- PR: https://git.openjdk.org/jfx22u/pull/28 From duke at openjdk.org Mon May 13 18:20:25 2024 From: duke at openjdk.org (smith3390s) Date: Mon, 13 May 2024 18:20:25 GMT Subject: RFR: 8291908: VirtualFlow creates unneeded empty cells In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 14:30:40 GMT, Johan Vos wrote: > When calculating the viewportOffset, we now already take into account that cells will have to shift. > > This prevents the creation of temporary empty cells in the layout phase. > One test needed to be fixed, since the number of invocations to updateItem() was hardcoded (and it > is decreased by this commit). @johanvos I encountered the bug initially described here: https://bugs.openjdk.org/browse/JDK-8291467 when I advanced from JavaFX 17 to 19.0.2.1. You had fixed it and it was released in JavaFX 20. In my application this tracks. The problem is indeed fixed in JavaFX 20. However, it seems broken again in JavaFX 21.0.3. Is there a regression test that could confirm what I am seeing? ------------- PR Comment: https://git.openjdk.org/jfx/pull/863#issuecomment-2108509939 From hmeda at openjdk.org Tue May 14 05:29:22 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 14 May 2024 05:29:22 GMT Subject: RFR: 8331748: Update libxml2 to 2.12.6 Message-ID: Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen ------------- Commit messages: - whitespace correction - update md file - Configure libxml on windows - configure libxml on linux - add missing headers - Update libxml to v2.12.6 Changes: https://git.openjdk.org/jfx/pull/1453/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1453&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331748 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod Patch: https://git.openjdk.org/jfx/pull/1453.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1453/head:pull/1453 PR: https://git.openjdk.org/jfx/pull/1453 From duke at openjdk.org Tue May 14 06:13:20 2024 From: duke at openjdk.org (robbiezl) Date: Tue, 14 May 2024 06:13:20 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: <__tkrmENQhJcl7slNpi1BCUP-G0ufZ23JO-nSXFnLHg=.630096f9-f94c-4e86-ab64-a275e04c3126@github.com> On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I've been following this request for a long time, why did it suddenly closed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2109332980 From jvos at openjdk.org Tue May 14 06:26:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 14 May 2024 06:26:07 GMT Subject: RFR: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 05:21:37 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen @tiainen can you do a build/review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1453#issuecomment-2109378318 From duke at openjdk.org Tue May 14 11:04:20 2024 From: duke at openjdk.org (Glavo) Date: Tue, 14 May 2024 11:04:20 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Mon, 13 May 2024 14:51:03 GMT, Thiago Milczarek Sayao wrote: > I will no longer commit to this change. Why? I'm getting ready to test this PR in the [HMCL](https://github.com/HMCL-dev/HMCL) community, and I expect it will address a lot of complaints from Linux users. HMCL is a popular app with hundreds of thousands of users, most of whom are from China. Although there are fewer Linux users among them, I believe this can get enough feedback. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2109903935 From hmeda at openjdk.org Tue May 14 12:06:22 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 14 May 2024 12:06:22 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 Message-ID: Update SQLite to v3.45.3.Verified build on all platforms. Sanity testing looks fine. ------------- Commit messages: - whitespace correction - Update sqlite to v3.45.3 Changes: https://git.openjdk.org/jfx/pull/1454/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329011 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod Patch: https://git.openjdk.org/jfx/pull/1454.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1454/head:pull/1454 PR: https://git.openjdk.org/jfx/pull/1454 From kcr at openjdk.org Tue May 14 13:24:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 May 2024 13:24:07 GMT Subject: RFR: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 05:21:37 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen Reviewers: @tiainen @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1453#issuecomment-2110233307 From kcr at openjdk.org Tue May 14 13:25:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 May 2024 13:25:09 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 11:45:06 GMT, Hima Bindu Meda wrote: > Update SQLite to v3.45.3.Verified build on all platforms. Sanity testing looks fine. Reviewers: @tiainen @kevinrushforth @johanvos do you also want to review or is Joeri's review OK? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1454#issuecomment-2110235435 PR Comment: https://git.openjdk.org/jfx/pull/1454#issuecomment-2110237796 From fkirmaier at openjdk.org Tue May 14 13:40:12 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 14 May 2024 13:40:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 14:49:26 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of the getViewportLength() Ok, I've updated the CSR accrodingly together with Eduard. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2110269379 From eduard.sdv at web.de Tue May 14 13:46:32 2024 From: eduard.sdv at web.de (Eduard Sedov) Date: Tue, 14 May 2024 15:46:32 +0200 Subject: prism.maxvram limitation Message-ID: Hi all, There is a long-lived bug in JavaFX: JDK-8089112: Need to handle the case of a failed texture load when rendering large images JavaFX manages a pool of resources that is limited to 512Mbytes by default. This limit can be increased by setting the 'prism.maxvram' system property. This limit is reasonable for the GraphicsPipelines (the D3DPipeline and the ES2Pipeline) that are backed by a graphics device that has such a limitation. But it does not make sense for pipelines that use only the main memory: the J2DPipeline and perhaps the SWPipeline. The J2DPipeline is currently used for printing. For example, printing an image on Letter paper using 600PPI printer requires 134_640_000 bytes. When the printed image is redirected to a PDF printer, even higher resolution is needed to get adequate quality because the PDF can zoom in. This often exceeds the limitation and ends in a NullPointerException if the allocated textures exceed the specified maxvram value. There is no way to specify different values for each pipeline or to remove the limitation for software pipelines. I would add this possibility? What do you think? Thanks, Eduard ?? From jvos at openjdk.org Tue May 14 14:26:08 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 14 May 2024 14:26:08 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 13:23:06 GMT, Kevin Rushforth wrote: > @johanvos do you also want to review or is Joeri's review OK? In Joeri I trust :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1454#issuecomment-2110380422 From kcr at openjdk.org Tue May 14 14:40:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 May 2024 14:40:08 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 14:23:18 GMT, Johan Vos wrote: > In Joeri I trust :) Me, too. :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1454#issuecomment-2110417688 From jvos at openjdk.org Tue May 14 14:47:12 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 14 May 2024 14:47:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 17:45:39 GMT, Andy Goryachev wrote: > > the idea about mapping scroll events to the top/bottom of a cell is hinted in the code though > > could you please point to these places? I'm not sure I understand the question, as this is exactly what the PR is doing. The scrollToTop/scrollToBottom is replaced with a scroll of X pixels. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2110436251 From sykora at openjdk.org Tue May 14 15:48:07 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 14 May 2024 15:48:07 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 11:45:06 GMT, Hima Bindu Meda wrote: > Update SQLite to v3.45.3.Verified build on all platforms. Sanity testing looks fine. Everything built fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1454#pullrequestreview-2055796129 From kcr at openjdk.org Tue May 14 17:59:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 May 2024 17:59:13 GMT Subject: RFR: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: <-8ApjgVk1IKUcyg7VcMBcXJH49uMNHnTrnU50W92YeA=.e651b0ba-4786-4b14-9e99-0beb79097b20@github.com> On Tue, 14 May 2024 11:45:06 GMT, Hima Bindu Meda wrote: > Update SQLite to v3.45.3.Verified build on all platforms. Sanity testing looks fine. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1454#pullrequestreview-2056068196 From mfox at openjdk.org Tue May 14 18:45:12 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 14 May 2024 18:45:12 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: <5e4e8YYMWDZJkUt-YkNG4S_cPLyWMfcvBcsKc3e6pj4=.52959ca8-4b40-4ba8-886e-29689f5a265c@github.com> On Sat, 4 May 2024 22:55:13 GMT, Martin Fox wrote: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. I now understand what?s going wrong on Linux but I don?t know how to fix it. When the test case tries to leave the innermost loop (let?s call it A) the cross-platform Java code calls Application.leaveNestedEventLoop to tell glass that the loop should exit. But before the loop can exit the test case starts a new loop leading to a call to Application.enterNestedEventLoop. On Mac the leaveNestedEventLoop call sets a few global state variables in glass and the enterNestedEventLoop call wipes out all those changes. So as far as glass is concerned the leaveNestedEventLoop call was never made. This works because the cross-platform Java code is holding onto an object that represents loop A; it?s down one level in the event loop stack and marked as LEAVING. When that object reaches the top of the event loop stack the core will once again call Application.leaveNestedEventLoop to exit loop A. On Linux leaveNestedEventLoop makes changes in glass that cannot be erased or undone (it calls gtk_main_quit which updates internal GTK state that we don?t have access to). In the end GTK will exit the loops in the correct order but it will exit loop A before the core code has a chance to call Application.leaveNestedEventLoop again. This is throwing off the bookkeeping including some debug checks. (JavaFX struggles with this scenario because the original test case behaves in such an unexpected way. While processing a click event on a modal stage the event handler hides that modal and then immediately starts a new modal. The original modal can?t really go away; the handler for the click event originated there and is still in progress. That first modal might not be visible but it can?t truly close until the second modal is dismissed.) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2110892622 From angorya at openjdk.org Tue May 14 18:53:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 May 2024 18:53:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Tue, 14 May 2024 14:44:58 GMT, Johan Vos wrote: > I'm not sure I understand the question I thought there were specific comments somewhere in the code. Never mind then. Thank you for responding! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2110915337 From kcr at openjdk.org Tue May 14 18:57:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 14 May 2024 18:57:13 GMT Subject: RFR: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 05:21:37 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen Looks good. All testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1453#pullrequestreview-2056175249 From mfox at openjdk.org Tue May 14 20:05:20 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 14 May 2024 20:05:20 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I do hope this PR is revived. I've never been able to configure a useable IME on Ubuntu with XIM enabled. I think sticking with XIM is tantamount to not having a functioning IME. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2111045286 From mfox at openjdk.org Tue May 14 22:29:18 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 14 May 2024 22:29:18 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: > On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. > > This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. > > (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) > > This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. Martin Fox 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 ten additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - Comment fixes - Consistency in naming conventions and comment cleanup. - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - Expanded robot lookup table, general cleanup - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - Resolving duplicates for Robot, fallback for getKeyCodeForChar - Merge remote-tracking branch 'upstream/master' into linuxcharcombo - KeyCharacterCombination fixes on Linux ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1373/files - new: https://git.openjdk.org/jfx/pull/1373/files/6de7864f..9aba1b0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1373&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1373&range=00-01 Stats: 35228 lines in 1034 files changed: 19566 ins; 6880 del; 8782 mod Patch: https://git.openjdk.org/jfx/pull/1373.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1373/head:pull/1373 PR: https://git.openjdk.org/jfx/pull/1373 From angorya at openjdk.org Tue May 14 22:30:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 14 May 2024 22:30:07 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll [v2] In-Reply-To: References: Message-ID: <3hczg3iYb8BQOSA4y7nWlybReY2zVm1E2lA5ukZsMFY=.73c7babe-f2c0-485c-b9f6-c717f7351fd1@github.com> On Thu, 9 May 2024 09:38:31 GMT, Karthik P K wrote: >> The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the items. Fixed the issue by restoring the selection in this case. >> >> Added a unit test to validate the fix. >> [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) is also fixed with this change and added a unit test for the same. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix JDK-8279139 It looks like we have quite a few bugs related to different aspects of ComboBox. This change is definitely an improvement, as it fixes the scenario described in JDK-8279140. This PR changes parts of the code that fixed JDK-8087838. While I don't see a regression in respect to JDK-8087838, I do see a different behavior with and without this fix in JDK-8090221, using the test app there (to be specific, with the fix in this PR, the tester in JDK-8090221 continues to display the selected item in the combo box even though the output shows `Selected Item After: null` Do you think that JDK-8090221 scenario is a different case and should be addressed separately? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1452#issuecomment-2111241863 From mfox at openjdk.org Tue May 14 23:57:07 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 14 May 2024 23:57:07 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: <8AuQRZ2LXOR4fINonYLnKXi8SCYckAdm-t8yA0BgF94=.3d7f184a-8ba9-4c8c-983a-d00a70e2d631@github.com> On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote: >> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. >> >> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. >> >> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) >> >> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. > > Martin Fox 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 ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Comment fixes > - Consistency in naming conventions and comment cleanup. > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Expanded robot lookup table, general cleanup > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Resolving duplicates for Robot, fallback for getKeyCodeForChar > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - KeyCharacterCombination fixes on Linux I've updated to the latest master. This will probably be the last time I refresh this pull request; I can only hold off the bots for so long. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2111343296 From kpk at openjdk.org Wed May 15 05:54:12 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 15 May 2024 05:54:12 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll [v2] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 09:38:31 GMT, Karthik P K wrote: >> The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the items. Fixed the issue by restoring the selection in this case. >> >> Added a unit test to validate the fix. >> [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) is also fixed with this change and added a unit test for the same. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix JDK-8279139 Yes there are few bugs related to ComboBox. I think we can fix JDK-8090221 separately. The issue JDK-8279139, which is closed as duplicate of this issue is fixed, but changing the test slightly shows another issue which is mentioned in JDK-8263942. Since we have different scenarios like these, we can fix these issue with these PRs one by one. So I believe other issues can be fixed separately. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1452#issuecomment-2111637496 From duke at openjdk.org Wed May 15 05:57:18 2024 From: duke at openjdk.org (leewyatt) Date: Wed, 15 May 2024 05:57:18 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Tue, 14 May 2024 10:59:10 GMT, Glavo wrote: > I will no longer commit to this change. I've been closely following this PR and sincerely hope it can be reopened; it is of great significance and has a far-reaching impact. Thank you for your efforts. I also respect your decision, but I strongly wish for this PR to be reconsidered. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2111639052 From arapte at openjdk.org Wed May 15 06:52:14 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 15 May 2024 06:52:14 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> References: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> Message-ID: On Mon, 6 May 2024 23:14:11 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > vertical scrolling tests LGTM... ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1393#pullrequestreview-2057040934 From sykora at openjdk.org Wed May 15 08:34:11 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Wed, 15 May 2024 08:34:11 GMT Subject: RFR: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 05:21:37 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen All tests are green here too. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1453#pullrequestreview-2057279996 From martin at martinfox.com Wed May 15 14:49:47 2024 From: martin at martinfox.com (Martin Fox) Date: Wed, 15 May 2024 07:49:47 -0700 Subject: KeyCode in the javafx.scene.robot.Robot interface In-Reply-To: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> References: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> Message-ID: Mark, You may already know this but before JavaFX 21 the Mac and Windows Robot code had some long-standing bugs with non-US keyboards. Linux is in better shape but you can encounter problems if the user has installed multiple layouts (I have a PR pending to fix that). That might explain some of the flakey behavior you?ve been seeing. Your approach might also invoke an unexpected dead key depending on what modifiers you?re probing. With one exception JavaFX doesn?t have any facility for querying the keyboard layout. It relies on the platform code to take in keyboard events and translate them to JavaFX events on the fly. The exception is the internal call Toolkit.getKeyCodeForChar which attempts to map from a character to a KeyCode and is used to match shortcuts specified as KeyCharacterCombinations. Unfortunately the current implementation on Mac and Linux can?t really be extended to cover the sort of testing you?re trying to do. (On any OS the keyboard machinery is designed to take a series of physical keystrokes and produce a series of characters. Attempting to go in the opposite direction is fraught with complications particularly for punctuation and symbols. It?s faster and more reliable to wait for the user to type something and record what happens. That?s how getKeyCodeForChar is implemented on the Mac; until the user types something it yields no results. Linux is currently buggy but the PR to fix it adopts the same approach as the Mac.) JavaFX needs a better framework for testing text entry and I?ve thought about how that might look. But my priorities might be different than yours. Based on the bugs I?ve seen the biggest issue is that developers only test on the platforms and layouts they use. Much of this is due to lack of awareness but it?s also a big hurdle to have to buy Mac, Windows, and Linux boxes and then manually switch between layouts to test. My ideal framework would be based on emulated keyboards so, say, a U.S. Windows developer could generate a key event stream that corresponds to a Spanish Mac layout. That approach wouldn?t involve sending platform events through the OS. Extending the Robot to make it easier to, say, target punctuation and symbols via platform events would be nice to have but not essential (IMHO). So, no, you?re not missing anything exposed or under the hood. The approach you?re taking is probably the best that can be done with the current API. Martin > On May 12, 2024, at 3:16?AM, Mark Raynsford wrote: > > Hello! > > I maintain a test harness for JavaFX applications: > > https://www.github.com/io7m-com/xoanon > > I expose an interface that uses the javafx.scene.robot.Robot > interface internally, but I expose a slightly higher level > API that allows for (amongst other things) typing text as strings > on components rather than sending individual key codes. > > The problem I immediately run into is that KeyCodes are keyboard > layout specific, and there doesn't appear to be any way to detect > what keyboard layout is in use. If I, for example, send the KeyCode for > the `@` symbol, I'll actually get `"` on some keyboard layouts. This > can cause some types of tests to fail, even though the code is correct. > > Consider a test where an email address is typed into a text field, and > then the form containing the field is checked to see if the text field > accepted/rejected the text as being a valid email address. On some > keyboard layouts, a test that sends the string "someone at example.com" > will fail because what ends up in the text field is actually > "someone"example.com". > > I provide a workaround for this: At the start of the test suite run, > xoanon will send every KeyCode to a text field one at a time and see > what character appeared in the text field as a result. It then builds a > mapping between characters to KeyCodes, and it can then do the > translations as necessary when running the rest of the test suite: > > https://github.com/io7m-com/xoanon?tab=readme-ov-file#keymap-generation > > Unfortunately, this is still rather flaky. This often seems to fail more > or less at random for reasons that aren't clear to me. > > Is there some way the Robot interface could be extended to allow for > typing strings? Failing that, is there some way JavaFX could advertise > the underlying keyboard map? I feel like some underlying component must > know the information I'm trying to infer, but it doesn't seem to be > exposed anywhere that I've been able to find. > > -- > Mark Raynsford | https://www.io7m.com From angorya at openjdk.org Wed May 15 15:01:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 15:01:19 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll [v2] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 09:38:31 GMT, Karthik P K wrote: >> The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the items. Fixed the issue by restoring the selection in this case. >> >> Added a unit test to validate the fix. >> [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) is also fixed with this change and added a unit test for the same. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix JDK-8279139 looks good. thank you for adding the tests! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1452#pullrequestreview-2058284727 From arapte at openjdk.org Wed May 15 15:15:35 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 15 May 2024 15:15:35 GMT Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao wrote: > Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration. > > It seems i3 replies with decorated sizes, even if window is not decorated. > > Won't hurt other WMs. I could verify that this change fixes the issue with i3 window manager. Shall do little more testing and update. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2112824722 From hmeda at openjdk.org Wed May 15 15:17:16 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 15 May 2024 15:17:16 GMT Subject: Integrated: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 14 May 2024 11:45:06 GMT, Hima Bindu Meda wrote: > Update SQLite to v3.45.3.Verified build on all platforms. Sanity testing looks fine. This pull request has now been integrated. Changeset: 581e3a70 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/581e3a70a45a550a97e391e06735f4837336ada8 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod 8329011: Update SQLite to 3.45.3 Reviewed-by: sykora, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1454 From hmeda at openjdk.org Wed May 15 15:19:03 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 15 May 2024 15:19:03 GMT Subject: Integrated: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: <9-7HL2L1htw39le46g9yWUvDQc7iuKFL-te7YCZBPYM=.f477755f-7fa7-4d21-b40c-462315c45c05@github.com> On Tue, 14 May 2024 05:21:37 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.6. Verified build and sanity testing on all platforms. No issue seen This pull request has now been integrated. Changeset: 97b14025 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/97b1402501983f121f75c24a510f466837fa2ecc Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod 8331748: Update libxml2 to 2.12.6 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1453 From jvos at openjdk.org Wed May 15 16:03:47 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 15 May 2024 16:03:47 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: <-l0FdVHOwxr52LIO4m4BRmaM_FPL3rIEAw7hR8sOGnI=.9f08f323-4d56-452c-bd39-718b929a5794@github.com> On Thu, 9 May 2024 19:48:19 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add more type info I think this PR is ready for review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-2112928451 From kpk at openjdk.org Wed May 15 16:07:05 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 15 May 2024 16:07:05 GMT Subject: RFR: 8279140: ComboBox can lose selected value on item change via setAll [v2] In-Reply-To: <3hczg3iYb8BQOSA4y7nWlybReY2zVm1E2lA5ukZsMFY=.73c7babe-f2c0-485c-b9f6-c717f7351fd1@github.com> References: <3hczg3iYb8BQOSA4y7nWlybReY2zVm1E2lA5ukZsMFY=.73c7babe-f2c0-485c-b9f6-c717f7351fd1@github.com> Message-ID: <5PX4GsuSK3jWtFEZqdsKhbKU7ubFoYytV1VMsgKRxpo=.66fbc081-c87e-470b-b4ef-29cb559bd852@github.com> On Tue, 14 May 2024 22:27:25 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix JDK-8279139 > > It looks like we have quite a few bugs related to different aspects of ComboBox. This change is definitely an improvement, as it fixes the scenario described in JDK-8279140. > > This PR changes parts of the code that fixed JDK-8087838. While I don't see a regression in respect to JDK-8087838, I do see a different behavior with and without this fix in JDK-8090221, using the test app there (to be specific, with the fix in this PR, the tester in JDK-8090221 continues to display the selected item in the combo box even though the output shows `Selected Item After: null` > > Do you think that JDK-8090221 scenario is a different case and should be addressed separately? Thanks for reviewing @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1452#issuecomment-2112931888 From kpk at openjdk.org Wed May 15 16:07:07 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 15 May 2024 16:07:07 GMT Subject: Integrated: 8279140: ComboBox can lose selected value on item change via setAll In-Reply-To: References: Message-ID: On Tue, 7 May 2024 10:10:23 GMT, Karthik P K wrote: > The `ComboBox` value was not set to previously selected value in the item list change listener when `setAll` method is used to change the items. Fixed the issue by restoring the selection in this case. > > Added a unit test to validate the fix. > [JDK-8279139](https://bugs.openjdk.org/browse/JDK-8279139) is also fixed with this change and added a unit test for the same. This pull request has now been integrated. Changeset: 88aad93d Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/88aad93d07b36c8b32afd701c9180753db975e10 Stats: 67 lines in 2 files changed: 63 ins; 3 del; 1 mod 8279140: ComboBox can lose selected value on item change via setAll Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1452 From jpereda at openjdk.org Wed May 15 16:23:21 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 15 May 2024 16:23:21 GMT Subject: [jfx21u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField Message-ID: <6i7SOOyyD_8DHfjoldP_L8sjCw9ZAZd6vm7JVOx45NI=.b6d2d036-6023-4d97-89bf-fc35f296cff5@github.com> Hi all, This pull request contains a backport of commit [d3da033a](https://github.com/openjdk/jfx/commit/d3da033a2dd5c287733545935242a8d1f71c0554) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Oliver Kopp on 8 May 2024 and was reviewed by Andy Goryachev, Kevin Rushforth and Ambarish Rapte. The backport is almost clean: While cherry picking the mainline commit, a minor merge conflict was shown at the file `tests/system/src/test/.classpath`: The mainline file has a few additional exports compared to 21u, which are not needed here. Thanks! ------------- Commit messages: - Backport d3da033a2dd5c287733545935242a8d1f71c0554 Changes: https://git.openjdk.org/jfx21u/pull/57/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=57&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330462 Stats: 147 lines in 5 files changed: 142 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx21u/pull/57.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/57/head:pull/57 PR: https://git.openjdk.org/jfx21u/pull/57 From angorya at openjdk.org Wed May 15 16:49:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 16:49:14 GMT Subject: [jfx21u] RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: <6i7SOOyyD_8DHfjoldP_L8sjCw9ZAZd6vm7JVOx45NI=.b6d2d036-6023-4d97-89bf-fc35f296cff5@github.com> References: <6i7SOOyyD_8DHfjoldP_L8sjCw9ZAZd6vm7JVOx45NI=.b6d2d036-6023-4d97-89bf-fc35f296cff5@github.com> Message-ID: On Wed, 15 May 2024 16:20:04 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a backport of commit [d3da033a](https://github.com/openjdk/jfx/commit/d3da033a2dd5c287733545935242a8d1f71c0554) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Oliver Kopp on 8 May 2024 and was reviewed by Andy Goryachev, Kevin Rushforth and Ambarish Rapte. > > The backport is almost clean: While cherry picking the mainline commit, a minor merge conflict was shown at the file `tests/system/src/test/.classpath`: The mainline file has a few additional exports compared to 21u, which are not needed here. > > Thanks! looking good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx21u/pull/57#pullrequestreview-2058538870 From arapte at openjdk.org Wed May 15 17:23:10 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 15 May 2024 17:23:10 GMT Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: <1IaJDOCzKg0kLS4FzFh3kJPK5JH99dyBu5ANJ_7L4kk=.699f9a49-a301-465b-80eb-47c057b3af3a@github.com> On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao wrote: > Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration. > > It seems i3 replies with decorated sizes, even if window is not decorated. > > Won't hurt other WMs. LGTM, tested with and without fix, with and without i3 window manager. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1437#pullrequestreview-2058602510 From tsayao at openjdk.org Wed May 15 17:36:10 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 15 May 2024 17:36:10 GMT Subject: Integrated: 8329821: [Linux] When using i3 WM, menus are incorrectly sized In-Reply-To: References: Message-ID: On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao wrote: > Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration. > > It seems i3 replies with decorated sizes, even if window is not decorated. > > Won't hurt other WMs. This pull request has now been integrated. Changeset: a7627fa8 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/a7627fa8d4c0c2595d359a2656daf2f6005ee0f5 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8329821: [Linux] When using i3 WM, menus are incorrectly sized Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1437 From kcr at openjdk.org Wed May 15 18:48:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 18:48:31 GMT Subject: RFR: 8332313: Update code review guidelines Message-ID: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Update the code review guidelines for JavaFX. The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. The source branch has three commits: 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. 2. Update `README-code-reviews.md` with new guidelines 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. The updates are: * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section * Update the `CONTRIBUTING.md` page to highlight important requirements ------------- Commit messages: - Update CONTRIBUTING.md and README-code-reviews.md - 8332313: Update code review guidelines - Convert Code Review Policies Wiki to README-code-reviews.md Changes: https://git.openjdk.org/jfx/pull/1455/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332313 Stats: 115 lines in 2 files changed: 106 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1455.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1455/head:pull/1455 PR: https://git.openjdk.org/jfx/pull/1455 From kcr at openjdk.org Wed May 15 18:48:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 18:48:31 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements Reviewers: @johanvos @andy-goryachev-oracle @arapte @prrace I'd like at least 3 "R"eviewers to review this. Committers and Authors are also welcome to provide feedback. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1455#issuecomment-2113119065 From angorya at openjdk.org Wed May 15 18:53:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 18:53:21 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements CONTRIBUTING.md line 52: > 50: > 51: * File a bug in JBS for every pull request > 52: for line 53, would it make more sense to use this link https://bugs.openjdk.org/projects/JDK/issues/ ? README-code-reviews.md line 10: > 8: > 9: __Project Co-Lead__: Kevin Rushforth (kcr)
> 10: __Project Co-Lead__: Johan Vos (jvos) There are two sets of ids - one for OpenJFX/JBS and one for Github. This might be confusing sometimes, should we list both? README-code-reviews.md line 63: > 61: Here is a list of things to keep in mind when reviewing a PR. This applies to anyone doing a review, but especially a "R"eviewer: > 62: > 63: * Make sure you understand why there was an issue to begin with, and why/how the proposed PR solves the issue Perhaps this should be noted as a required step for the PR author (maybe as a template text in the PR description?). README-code-reviews.md line 64: > 62: > 63: * Make sure you understand why there was an issue to begin with, and why/how the proposed PR solves the issue > 64: * Focus first on substantive comments rather than stylistic comments this is not as important as the next two. README-code-reviews.md line 66: > 64: * Focus first on substantive comments rather than stylistic comments > 65: * Consider the risk of regression > 66: * Consider any compatibility concerns regression and compatibility risks are probably the most important aspects of the code review from the "R"eviewer's perspective. Perhaps this should be emphasized somehow? README-code-reviews.md line 78: > 76: * All substantive feedback has been addressed, especially any objections from one with a Reviewer role. > 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. > 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends / or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. nit pick: 24 hours does not always equal to one business day. A long weekend may extend the waiting period to 96 hours, a "winter break" might span the whole week. README-code-reviews.md line 79: > 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. > 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends / or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. > 79: * Double-check the commit message before you integrate. Skara will list it near the top of your PR. is this needed? SKARA makes sure that it matches the JBS title. README-code-reviews.md line 83: > 81: #### A. Low-impact bug fixes. > 82: > 83: These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including most new tests), doc fixes, and fixes to sample applications (including most new samples). I think the main criteria is regression and compatibility impact. Should we expand upon that here? README-code-reviews.md line 99: > 97: Feature requests come with a responsibility beyond just saying "here is the code for this cool new feature, please take it". There are many factors to consider for even small features. Larger features will need a significant contribution in terms of API design, coding, testing, maintainability, etc. > 98: > 99: A feature should be discussed up-front on the openjfx-dev mailing list to get early feedback on the concept (is it a feature we are likely to accept) and the direction the API and/or implementation should take. are there any special rules to gauging the consensus? what happens when one party in a discussion stops responding? README-code-reviews.md line 101: > 99: A feature should be discussed up-front on the openjfx-dev mailing list to get early feedback on the concept (is it a feature we are likely to accept) and the direction the API and/or implementation should take. > 100: > 101: To ensure that new features are consistent with the rest of the API and the desired direction of the Project, a CSR is required for a new Feature, API addition, or behavioral change. The CSR must be reviewed and approved by a "lead" of the Project. Currently this is either Kevin Rushforth or Johan Vos as indicated above. this paragraph feels extremely nebulous. a minor issue is that CSR cannot be written in full detail before the draft PR is created (a PoS is written), a larger issue is that a decision to implement a feature might need a better process - is one lead approval sufficient? what happens when leads disagree? README-code-reviews.md line 103: > 101: To ensure that new features are consistent with the rest of the API and the desired direction of the Project, a CSR is required for a new Feature, API addition, or behavioral change. The CSR must be reviewed and approved by a "lead" of the Project. Currently this is either Kevin Rushforth or Johan Vos as indicated above. > 102: > 103: The review of the implementation follows the same "two reviewer" standard for higher-impact changes as described in category B. The two code reviewers for the implementation may or may not include the Lead who reviewed the CSR. The review / approval of the CSR is an independent step from the review / approval of the code change, although they can proceed in parallel. it is not clear (at least to me) the required order in respect to CSR approval. for a new feature, does the CSR need to be approved before the work can be started, or the draft PR is published, or an PR enters its "rfr" stage, or just before the integration? Or perhaps it should be clarified that the CSR is just a human-readable, specially formatted specification of the *change*, and it is an integral part of the new feature that needs to be approved before the feature can be integrated? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602050560 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602061399 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602072022 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602072829 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602075277 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602082570 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602083761 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602085558 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602098222 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602095257 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602105550 From kcr at openjdk.org Wed May 15 18:59:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 18:59:06 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 18:05:10 GMT, Andy Goryachev wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > CONTRIBUTING.md line 52: > >> 50: >> 51: * File a bug in JBS for every pull request >> 52: > > for line 53, would it make more sense to use this link > https://bugs.openjdk.org/projects/JDK/issues/ > ? Whether or not that might be a better link, it's unrelated to this PR. The scope of this PR is limited to guidelines surrounding reviewing, integrating, and sponsoring PRs. > README-code-reviews.md line 10: > >> 8: >> 9: __Project Co-Lead__: Kevin Rushforth (kcr)
>> 10: __Project Co-Lead__: Johan Vos (jvos) > > There are two sets of ids - one for OpenJFX/JBS and one for Github. This might be confusing sometimes, should we list both? Not sure what you mean, but it doesn't seem related to this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602112407 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602113564 From nlisker at openjdk.org Wed May 15 19:36:18 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 15 May 2024 19:36:18 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements README-code-reviews.md line 48: > 46: All code reviews must be done via a pull request submitted against this GitHub repo, [openjdk/jfx](https://github.com/openjdk/jfx). A JBS bug ID must exist before the pull request will be reviewed. See [CONTRIBUTING.md](CONTRIBUTING.md) for information on how to submit a pull request. > 47: > 48: All fixes must be reviewed by at least one reviewer with the "Reviewer" role (aka a "R"eviewer). We have a different code review threshold for different types of changes. If there is disagreement as to whether a fix is low-impact or high-impact, then it is considered high-impact. In other words we will always err on the side of quality by "rounding up" to the next higher category. The contributor can say whether they think something is low-impact or high-impact, but It is up to a Reviewer to confirm this. A Reviewer either adds a comment indicating that they think a single review is sufficient, or else issues the Skara `/reviewers 2` command requesting a second reviewer (a Reviewer can request more than 2 reviewers in some cases where a fix might be especially risky or cut across multiple functional areas). "but **It** is" -> it README-code-reviews.md line 48: > 46: All code reviews must be done via a pull request submitted against this GitHub repo, [openjdk/jfx](https://github.com/openjdk/jfx). A JBS bug ID must exist before the pull request will be reviewed. See [CONTRIBUTING.md](CONTRIBUTING.md) for information on how to submit a pull request. > 47: > 48: All fixes must be reviewed by at least one reviewer with the "Reviewer" role (aka a "R"eviewer). We have a different code review threshold for different types of changes. If there is disagreement as to whether a fix is low-impact or high-impact, then it is considered high-impact. In other words we will always err on the side of quality by "rounding up" to the next higher category. The contributor can say whether they think something is low-impact or high-impact, but It is up to a Reviewer to confirm this. A Reviewer either adds a comment indicating that they think a single review is sufficient, or else issues the Skara `/reviewers 2` command requesting a second reviewer (a Reviewer can request more than 2 reviewers in some cases where a fix might be especially risky or cut across multiple functional areas). About requesting reviews. I think that only some people can request reviews through GitHub, I never managed to do it on this repo, probably a matter of permissions. Might worth clarifying how this works. README-code-reviews.md line 58: > 56: * Determine whether this needs 2 reviewers and whether it needs a CSR; issue the `/reviewers 2` or `/csr` command as needed > 57: * If you want to indicate your approval, but still feel additional reviewers are needed, you may increase the number of reviewers (e.g., from 2 to 3) > 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it Should a list of experts per area be available somewhere? The Wiki has an old "code ownership" table that is out of date. Usually you get to know the experts only after they have reviewed your code a couple of times. README-code-reviews.md line 60: > 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it > 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have > 60: I would add that it's a good idea to search for JBS issues similar/linked to the one being targeted. There are many unfound duplicates in JBS that arise only when searching, or at least closely linked ones (problems in `TableTreeView` often have "pseudo-duplicates" for `TreeView` and `TableView`, for example). I would explain (or link to where it is explained) when to close an issue a a duplicated vs. when to use the /add Skara command to bundle issues into the same fix. We might also find that the targeted issue is a regression of another issue. This is somewhat mentioned in the bullet point below "Consider the risk of regression". README-code-reviews.md line 60: > 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it > 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have > 60: Another thing to look out for is the targeting branch during rampdown. Should they all target master and then be backported as needed, or can some target the rampdown branch? README-code-reviews.md line 66: > 64: * Focus first on substantive comments rather than stylistic comments > 65: * Consider the risk of regression > 66: * Consider any compatibility concerns This might be included in this point already, but one thing I sometimes miss is the inadvertent introduction of new API (that will have to be deprecated if missed). This can happen with `protected` methods, default `public` constructors (esp. if a non-API constructor is removed), or if a class is moved from a non-exported to an exported package (something that you can't see by looking at the area you're reviewing, you need to check the `module-info`, or more practically, look at the package names). README-code-reviews.md line 68: > 66: * Consider any compatibility concerns > 67: * Check whether there is an automated test; if not, ask for one, if it is feasible > 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows These tests sometimes fail and we integrate anyway. I noticed that sometimes they need a few iterations to succeed. Are we really dependent on them? Edit: currently the Linux test is failing, and this PR can't be the reason. README-code-reviews.md line 69: > 67: * Check whether there is an automated test; if not, ask for one, if it is feasible > 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows > 69: * If the PR source branch hasn't synced up from master in a long time, or if there is an upstream commit not in the source branch that might interfere with the PR, ask the PR author to merge the latest upstream master. This is the only bullet point with a period at the end. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602118351 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602122027 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602145807 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602134914 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602135321 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602142181 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602125749 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602129587 From kcr at openjdk.org Wed May 15 19:46:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 19:46:13 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 18:20:22 GMT, Andy Goryachev wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 63: > >> 61: Here is a list of things to keep in mind when reviewing a PR. This applies to anyone doing a review, but especially a "R"eviewer: >> 62: >> 63: * Make sure you understand why there was an issue to begin with, and why/how the proposed PR solves the issue > > Perhaps this should be noted as a required step for the PR author (maybe as a template text in the PR description?). I like the idea of adding some additional information on "here's what makes a good PR" to the CONTRIBUTING guidelines. I'll either take a stab at this or else file a follow-on issue. > README-code-reviews.md line 64: > >> 62: >> 63: * Make sure you understand why there was an issue to begin with, and why/how the proposed PR solves the issue >> 64: * Focus first on substantive comments rather than stylistic comments > > this is not as important as the next two. Agreed. I'll move this bullet down. > README-code-reviews.md line 66: > >> 64: * Focus first on substantive comments rather than stylistic comments >> 65: * Consider the risk of regression >> 66: * Consider any compatibility concerns > > regression and compatibility risks are probably the most important aspects of the code review from the "R"eviewer's perspective. Perhaps this should be emphasized somehow? That's a good idea. > README-code-reviews.md line 83: > >> 81: #### A. Low-impact bug fixes. >> 82: >> 83: These are typically isolated bug fixes with little or no impact beyond fixing the bug in question; included in this category are test fixes (including most new tests), doc fixes, and fixes to sample applications (including most new samples). > > I think the main criteria is regression and compatibility impact. Should we expand upon that here? That seems like a good idea. > README-code-reviews.md line 99: > >> 97: Feature requests come with a responsibility beyond just saying "here is the code for this cool new feature, please take it". There are many factors to consider for even small features. Larger features will need a significant contribution in terms of API design, coding, testing, maintainability, etc. >> 98: >> 99: A feature should be discussed up-front on the openjfx-dev mailing list to get early feedback on the concept (is it a feature we are likely to accept) and the direction the API and/or implementation should take. > > are there any special rules to gauging the consensus? what happens when one party in a discussion stops responding? This is out of scope for this PR (this section is unchanged). It might be something to consider addressing in a follow-on enhancement, although I'm not sure I want to make it any more specific. > README-code-reviews.md line 101: > >> 99: A feature should be discussed up-front on the openjfx-dev mailing list to get early feedback on the concept (is it a feature we are likely to accept) and the direction the API and/or implementation should take. >> 100: >> 101: To ensure that new features are consistent with the rest of the API and the desired direction of the Project, a CSR is required for a new Feature, API addition, or behavioral change. The CSR must be reviewed and approved by a "lead" of the Project. Currently this is either Kevin Rushforth or Johan Vos as indicated above. > > this paragraph feels extremely nebulous. > > a minor issue is that CSR cannot be written in full detail before the draft PR is created (a PoS is written), > > a larger issue is that a decision to implement a feature might need a better process - is one lead approval sufficient? what happens when leads disagree? This is out of scope for this PR, but it might be something to consider addressing in a follow-on enhancement. > README-code-reviews.md line 103: > >> 101: To ensure that new features are consistent with the rest of the API and the desired direction of the Project, a CSR is required for a new Feature, API addition, or behavioral change. The CSR must be reviewed and approved by a "lead" of the Project. Currently this is either Kevin Rushforth or Johan Vos as indicated above. >> 102: >> 103: The review of the implementation follows the same "two reviewer" standard for higher-impact changes as described in category B. The two code reviewers for the implementation may or may not include the Lead who reviewed the CSR. The review / approval of the CSR is an independent step from the review / approval of the code change, although they can proceed in parallel. > > it is not clear (at least to me) the required order in respect to CSR approval. for a new feature, does the CSR need to be approved before the work can be started, or the draft PR is published, or an PR enters its "rfr" stage, or just before the integration? > > Or perhaps it should be clarified that the CSR is just a human-readable, specially formatted specification of the *change*, and it is an integral part of the new feature that needs to be approved before the feature can be integrated? This is out of scope for this PR, but it might be something to consider addressing in a follow-on enhancement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602156743 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602157447 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602157689 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602158932 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602148854 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602150110 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602150492 From kcr at openjdk.org Wed May 15 19:46:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 19:46:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements I replied to Andy's comments inline. Some of them are in unmodified sections and are out of scope for this, but I'll file a follow-on issue (P4). I'll address the rest of the feedback in a subsequent commit. ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2058843801 From angorya at openjdk.org Wed May 15 19:53:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 19:53:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:16:31 GMT, Nir Lisker wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 60: > >> 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it >> 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have >> 60: > > I would add that it's a good idea to search for JBS issues similar/linked to the one being targeted. There are many unfound duplicates in JBS that arise only when searching, or at least closely linked ones (problems in `TableTreeView` often have "pseudo-duplicates" for `TreeView` and `TableView`, for example). > > I would explain (or link to where it is explained) when to close an issue a a duplicated vs. when to use the /add Skara command to bundle issues into the same fix. > > We might also find that the targeted issue is a regression of another issue. This is somewhat mentioned in the bullet point below "Consider the risk of regression". Second this, although I think the bulk of the work should fall on the author of the PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602168856 From angorya at openjdk.org Wed May 15 19:56:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 19:56:14 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:23:25 GMT, Nir Lisker wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 66: > >> 64: * Focus first on substantive comments rather than stylistic comments >> 65: * Consider the risk of regression >> 66: * Consider any compatibility concerns > > This might be included in this point already, but one thing I sometimes miss is the inadvertent introduction of new API (that will have to be deprecated if missed). This can happen with `protected` methods, default `public` constructors (esp. if a non-API constructor is removed), or if a class is moved from a non-exported to an exported package (something that you can't see by looking at the area you're reviewing, you need to check the `module-info`, or more practically, look at the package names). I was wondering if there ought to be an unofficial checklist for things to look for? As new people become "R"eviewers, I think there is a value in accumulating collective wisdom in a checklist. I like checklists. > README-code-reviews.md line 68: > >> 66: * Consider any compatibility concerns >> 67: * Check whether there is an automated test; if not, ask for one, if it is feasible >> 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows > > These tests sometimes fail and we integrate anyway. I noticed that sometimes they need a few iterations to succeed. Are we really dependent on them? > > Edit: currently the Linux test is failing, and this PR can't be the reason. or is it? :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602171862 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602172232 From prr at openjdk.org Wed May 15 20:06:09 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 15 May 2024 20:06:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 18:56:29 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 10: >> >>> 8: >>> 9: __Project Co-Lead__: Kevin Rushforth (kcr)
>>> 10: __Project Co-Lead__: Johan Vos (jvos) >> >> There are two sets of ids - one for OpenJFX/JBS and one for Github. This might be confusing sometimes, should we list both? > > Not sure what you mean, but it doesn't seem related to this PR. He means people reading reviews are usually on github and your github ID is kevinrusforth, so they might be confused by "kcr" which is your openjdk id. Since the context is identifying OpenJDK Project leads, I think the OpenJDK ID is the right and only one to include here. At most you could clarify like (OpenJDK ID - kcr) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602181574 From jpereda at openjdk.org Wed May 15 20:12:16 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 15 May 2024 20:12:16 GMT Subject: [jfx21u] Integrated: 8330462: StringIndexOutOfBoundException when typing anything into TextField In-Reply-To: <6i7SOOyyD_8DHfjoldP_L8sjCw9ZAZd6vm7JVOx45NI=.b6d2d036-6023-4d97-89bf-fc35f296cff5@github.com> References: <6i7SOOyyD_8DHfjoldP_L8sjCw9ZAZd6vm7JVOx45NI=.b6d2d036-6023-4d97-89bf-fc35f296cff5@github.com> Message-ID: On Wed, 15 May 2024 16:20:04 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a backport of commit [d3da033a](https://github.com/openjdk/jfx/commit/d3da033a2dd5c287733545935242a8d1f71c0554) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Oliver Kopp on 8 May 2024 and was reviewed by Andy Goryachev, Kevin Rushforth and Ambarish Rapte. > > The backport is almost clean: While cherry picking the mainline commit, a minor merge conflict was shown at the file `tests/system/src/test/.classpath`: The mainline file has a few additional exports compared to 21u, which are not needed here. > > Thanks! This pull request has now been integrated. Changeset: 136dd663 Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/136dd663dd94f0db6cc583181e2059bc09425f3a Stats: 147 lines in 5 files changed: 142 ins; 0 del; 5 mod 8330462: StringIndexOutOfBoundException when typing anything into TextField Reviewed-by: angorya Backport-of: d3da033a2dd5c287733545935242a8d1f71c0554 ------------- PR: https://git.openjdk.org/jfx21u/pull/57 From jhendrikx at openjdk.org Wed May 15 20:18:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 15 May 2024 20:18:11 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements Marked as reviewed by jhendrikx (Committer). README-code-reviews.md line 79: > 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. > 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. > 79: * Verify the commit message. The Skara tooling adds a comment near the top of the PR with the commit message that will be used. You can add a summary to the commit message with the `/summary` command. You can add additional contributors with the `/contributor` command. Commands are issued by adding a comment to the PR that starts with a slash `/` character. The last sentence feels a bit out of place, as several places earlier in this document already mention slash commands. ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2058908894 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602186633 From jhendrikx at openjdk.org Wed May 15 20:18:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 15 May 2024 20:18:12 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:53:43 GMT, Andy Goryachev wrote: >> README-code-reviews.md line 68: >> >>> 66: * Consider any compatibility concerns >>> 67: * Check whether there is an automated test; if not, ask for one, if it is feasible >>> 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows >> >> These tests sometimes fail and we integrate anyway. I noticed that sometimes they need a few iterations to succeed. Are we really dependent on them? >> >> Edit: currently the Linux test is failing, and this PR can't be the reason. > > or is it? :-) Isn't this automatic? Seems weird you could integrate without these passing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602186713 From prr at openjdk.org Wed May 15 20:23:08 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 15 May 2024 20:23:08 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements CONTRIBUTING.md line 233: > 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. > 232: > 233: New code should be formatted consistently in accordance with the above guidelines. However, please do not reformat existing code as part of a bug fix. The makes more changes for code reviewers to track and review, and can lead to merge conflicts. If you want to reformat a class, do that in a separate pull request (which will need its own unique JBS bug ID). "The makes more changes" ? I think you mean "This" not "The" I'm not sure about the last sentence, it seems to encourage reformatting fixes which are just noise most of the time. README-code-reviews.md line 14: > 12: ### Reviewers > 13: > 14: The [List of Reviewers](https://openjdk.java.net/census#openjfx) is on the OpenJDK Census. We use ".org" now, not ".java.net" README-code-reviews.md line 40: > 38: ### 1. The Reviewer role for the OpenJFX Project > 39: > 40: We define a formal "Reviewer" role, similar to the JDK project. A [Reviewer](https://openjdk.java.net/census#openjfx) is responsible for reviewing code changes and helping to determine whether a change is suitable for including into OpenJFX. We expect Reviewers to feel responsible not just for their piece, but for the quality of the JavaFX library as a whole. In other words, the role of Reviewer is one of stewardship. See the following section for what constitutes a good review. (https://openjdk.java.net/census#openjfx) .org please BTW these very long source lines make it awkward to precisely identify the text I'm commenting on. README-code-reviews.md line 77: > 75: > 76: * All substantive feedback has been addressed, especially any objections from one with a Reviewer role. > 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. One thing to add here (or hereabouts) is that if someone has commented on your review and requested changes that in almost all cases you should expect that they will want to return to review the results. So DO NOT push without letting earlier reviewers who made substantive comments re-review. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602185573 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602187001 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602188630 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602198401 From prr at openjdk.org Wed May 15 20:23:09 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 15 May 2024 20:23:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:00:57 GMT, Nir Lisker wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 48: > >> 46: All code reviews must be done via a pull request submitted against this GitHub repo, [openjdk/jfx](https://github.com/openjdk/jfx). A JBS bug ID must exist before the pull request will be reviewed. See [CONTRIBUTING.md](CONTRIBUTING.md) for information on how to submit a pull request. >> 47: >> 48: All fixes must be reviewed by at least one reviewer with the "Reviewer" role (aka a "R"eviewer). We have a different code review threshold for different types of changes. If there is disagreement as to whether a fix is low-impact or high-impact, then it is considered high-impact. In other words we will always err on the side of quality by "rounding up" to the next higher category. The contributor can say whether they think something is low-impact or high-impact, but It is up to a Reviewer to confirm this. A Reviewer either adds a comment indicating that they think a single review is sufficient, or else issues the Skara `/reviewers 2` command requesting a second reviewer (a Reviewer can request more than 2 reviewers in some cases where a fix might be especially risky or cut across multiple functional areas). > > "but **It** is" -> it I think it worth noting that in skara syntax that isn't two people with the reviewer role. And tell people what to use if that is what they intend - eg if I have it right ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602190743 From prr at openjdk.org Wed May 15 20:23:10 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 15 May 2024 20:23:10 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:32:04 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 103: >> >>> 101: To ensure that new features are consistent with the rest of the API and the desired direction of the Project, a CSR is required for a new Feature, API addition, or behavioral change. The CSR must be reviewed and approved by a "lead" of the Project. Currently this is either Kevin Rushforth or Johan Vos as indicated above. >>> 102: >>> 103: The review of the implementation follows the same "two reviewer" standard for higher-impact changes as described in category B. The two code reviewers for the implementation may or may not include the Lead who reviewed the CSR. The review / approval of the CSR is an independent step from the review / approval of the code change, although they can proceed in parallel. >> >> it is not clear (at least to me) the required order in respect to CSR approval. for a new feature, does the CSR need to be approved before the work can be started, or the draft PR is published, or an PR enters its "rfr" stage, or just before the integration? >> >> Or perhaps it should be clarified that the CSR is just a human-readable, specially formatted specification of the *change*, and it is an integral part of the new feature that needs to be approved before the feature can be integrated? > > This is out of scope for this PR, but it might be something to consider addressing in a follow-on enhancement. It should be made clear (somewhere, at some point) that it would be rare for a CSR to be completed and approved before starting work on the implementation because the spec. almost always evolves as the fix is developed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602196255 From nlisker at openjdk.org Wed May 15 20:26:12 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 15 May 2024 20:26:12 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <9DHtGWaenwBZgu5-GlnaFVQrnEJsnv-LyC-vDvVFX4M=.f53b52e5-f99a-4b76-a905-030cf6153fc2@github.com> On Wed, 15 May 2024 20:08:10 GMT, John Hendrikx wrote: >> or is it? :-) > > Isn't this automatic? Seems weird you could integrate without these passing. > or is it? :-) ![image](https://github.com/openjdk/jfx/assets/37422899/8daab7cf-f050-4964-b8a6-731666422293) Looks to me like it is... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602201785 From angorya at openjdk.org Wed May 15 20:36:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 20:36:07 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:03:01 GMT, Phil Race wrote: >> Not sure what you mean, but it doesn't seem related to this PR. > > He means people reading reviews are usually on github and your github ID is kevinrusforth, > so they might be confused by "kcr" which is your openjdk id. > > Since the context is identifying OpenJDK Project leads, I think the OpenJDK ID is the right and only one to include here. At most you could clarify like (OpenJDK ID - kcr) exactly my point. when the majority of time is spent in the context of github (PR review etc) it might be confusing when one types `@jvos` and it's not found, or when within a PR there are references to both `jvos` and `johanvos` (see the very first comment in https://github.com/openjdk/jfx/pull/1388 ) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602212035 From angorya at openjdk.org Wed May 15 21:08:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 21:08:07 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote: >> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. >> >> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. >> >> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) >> >> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. > > Martin Fox 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 ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Comment fixes > - Consistency in naming conventions and comment cleanup. > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Expanded robot lookup table, general cleanup > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Resolving duplicates for Robot, fallback for getKeyCodeForChar > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - KeyCharacterCombination fixes on Linux In the context of the recent discussion on the mailing list, would it be possible to actually detect the keyboard layout? There is a limited number of layouts, so in theory that should be possible. Another question - I recall on Windows there is a way to enter certain key using Alt codes. Does this method exist on Linux? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2113454803 From john.hendrikx at gmail.com Wed May 15 21:34:39 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 15 May 2024 23:34:39 +0200 Subject: Proposal: Public InputMap (v2) In-Reply-To: References: Message-ID: I can only second this. If anything, the proposal highlights several fundamental problems in current JavaFX by how it is trying to work around them. The work around works for one area (key events) but does not address similar problems for other events. The work around will also further cement these problems making them harder to address in the future. I'll reiterate what I think are more fundamental issues that should be addressed: 1. Behaviors/Skins/Controls should not be hijacking events for their own purposes before the user has their say in their handling. If the user is not consuming the event (at any level), only then should it fall back to defaults. The reason why it currently works this way is because the public infrastructure for event handling is being used by Skin and Behavior implementations; this infrastructure however by its nature is a first come first serve system (unlike listeners), which makes it risky to share with users unless measures are taken to ensure there are no visible side effects of this sharing.? Effectively this also means Skins and Behaviors can *never* add a new event handler, or even a key mapping without risking breaking existing apps. Even consuming a new event in an existing handler, or changing its consumption pattern can cause breakage as it currently stands. 2. Separation of Behaviors and Skins. Even for complex controls this is possible, if there is a willingness to do so. This will open up far easier extension of the FX platform where the choice is not to either throw away all behavior and implement everything yourself, or hope you can sufficiently hack the existing skin (which were never designed for extension) to suit your needs. 3. Provide rock solid control primitives, and provide the infrastructure to build more complicated controls. I should be able to copy/paste any FX control, give it a new name, and then have it behave exactly as the original in all respects.? This may mean opening up (or more likely, evaluating and partially redesigning) certain private API's (like focus traversal). I feel strongly that these would provide far more value currently, and, as these are all aspects that can't be addressed easily by 3rd parties or be worked around, only FX developers can solve these. As far as the proposal is concerned, I feel that it is taking a giant leap towards a perceived solution for an X/Y type problem. I think we should be making far smaller incremental changes and fixes, and seeing what those bring.? This may eventually lead to an InputMap type system, but it could also lead to a place where the issue to provide it has become less urgent, giving us time to address other more fundamental problems. --John On 07/05/2024 10:44, Michael Strau? wrote: > Hi Andy! > > The updated proposal seems to be a slight refinement of the original > proposal, and I think most of the points raised in the previous > discussion still stand. > > As it is, I still think that this is an exceptionally large API > surface for what the feature can actually bring to the table. It's > overly specific in trying to solve problems for which general-purpose > APIs like event handlers can be extended to work just as well (and > open up many more use cases than just those of a bespoke control API). > > The fact that the API tries to fix a problem with the event system > itself (unpredictable invocation order) is a red flag. We should fix > this problem where it originates, which is the event API; crafting > workaround APIs in other parts of JavaFX doesn't seem to be the right > approach to me. This would also help to break the problem down into > more manageable chunks: improve the event system first, then see how > that influences the remaining problems that need to be solved. > > You provide several examples of what the InputMap API can do: > > > 1. Adding a new key mapping > > // creates a new key binding mapped to an external function > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> { > externalFunction(); > }); > > I don't see why this is needed. It doesn't seem to be easier than > using a plain old event handler, it's just different. > > > 2. Redefine an existing function > > // redefine function keeping existing key mappings > getInputMap().registerFunction(Tag.COPY, (control) -> customCopy()); > > If I want to change the meaning of the copy() method, can I not just > override the method and provide my own implementation? Plain old Java > seems to do the job. > > > 3. Map an existing function to a new binding > > // map a new key binding > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), Tag.COPY); > > Again, an event handler would do the job here. > > > 4. Obtain the default function > > // obtains the default function handler > FunctionHandler h = getInputMap().getDefaultFunction(Tag.COPY); > > If I override the copy() method to provide my own implementation, I > could also add a defaultCopy() method that calls the base > implementation. Then I can call both copy() and defaultCopy(). > (I don't know why I would want to do this, though.) > > > To summarize: the way I see it, your examples don't provide a > compelling reason why we need this new API. Given the size and > complexity of the proposal, I suggest to break the problem down into > more manageable parts, and solve the most fundamental issues first. At > the very least, the issue with event invocation ordering should be > solved in the event system. > > > > On Mon, Mar 11, 2024 at 4:22?PM Andy Goryachev > wrote: >> Dear JavaFX developers: >> >> >> >> Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were: >> >> >> >> desire for some static behavior to avoid the per-instance penalty >> clearer separation of concerns between controls, skins, and behaviors >> desire to have some sort of public API for behaviors >> need for addressing an issue with the event handler execution order between application and skins >> >> >> >> I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include: >> >> >> >> separation of SkinInputMap from the control's InputMap >> enabling static skin input maps for stateless behaviors >> explicit priority levels for event handlers and key mappings created by the application and by the skin >> >> >> >> The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls: >> >> >> >> complex popup-like controls: ComboBox, ColorPicker, DatePicker >> complex text input controls: PasswordField, TextArea, TextField >> control with a stateless behavior: TabPane >> >> >> >> as well as a brand new RichTextArea control being incubated [8]. >> >> >> >> Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. >> >> >> >> For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below. >> >> >> >> What do you think? >> >> -andy >> >> >> >> >> >> References >> >> >> >> [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md >> >> [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md >> >> [2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ >> >> [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395 >> >> [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 >> >> [5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior >> >> [6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md >> >> [7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html >> >> [8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >> From kcr at openjdk.org Wed May 15 22:24:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:06 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements Thanks for the additional feedback. I'll update the PR in the next day or two. I'll double-check that I addressed all of the comments. ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2059087200 From kcr at openjdk.org Wed May 15 22:24:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:07 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:07:06 GMT, Phil Race wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > CONTRIBUTING.md line 233: > >> 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. >> 232: >> 233: New code should be formatted consistently in accordance with the above guidelines. However, please do not reformat existing code as part of a bug fix. The makes more changes for code reviewers to track and review, and can lead to merge conflicts. If you want to reformat a class, do that in a separate pull request (which will need its own unique JBS bug ID). > > "The makes more changes" ? I think you mean "This" not "The" > > I'm not sure about the last sentence, it seems to encourage reformatting fixes which are just noise most of the time. Yeah, that was a typo (which I didn't notice when copying the block from the other doc). I'll fix it. And I agree with your concern, so I'll remove the last sentence. > README-code-reviews.md line 14: > >> 12: ### Reviewers >> 13: >> 14: The [List of Reviewers](https://openjdk.java.net/census#openjfx) is on the OpenJDK Census. > > We use ".org" now, not ".java.net" Yes, I missed this. I'll update. > README-code-reviews.md line 40: > >> 38: ### 1. The Reviewer role for the OpenJFX Project >> 39: >> 40: We define a formal "Reviewer" role, similar to the JDK project. A [Reviewer](https://openjdk.java.net/census#openjfx) is responsible for reviewing code changes and helping to determine whether a change is suitable for including into OpenJFX. We expect Reviewers to feel responsible not just for their piece, but for the quality of the JavaFX library as a whole. In other words, the role of Reviewer is one of stewardship. See the following section for what constitutes a good review. > > (https://openjdk.java.net/census#openjfx) > > .org please > > BTW these very long source lines make it awkward to precisely identify the text I'm commenting on. I'll fix it. > README-code-reviews.md line 77: > >> 75: >> 76: * All substantive feedback has been addressed, especially any objections from one with a Reviewer role. >> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. > > One thing to add here (or hereabouts) is that if someone has commented on your review and requested changes that in almost all cases you should expect that they will want to return to review the results. So DO NOT push without letting earlier reviewers who made substantive comments re-review. I'll add something about this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602296959 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602297934 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602298847 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602310947 From kcr at openjdk.org Wed May 15 22:24:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:08 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:33:37 GMT, Andy Goryachev wrote: >> He means people reading reviews are usually on github and your github ID is kevinrusforth, >> so they might be confused by "kcr" which is your openjdk id. >> >> Since the context is identifying OpenJDK Project leads, I think the OpenJDK ID is the right and only one to include here. At most you could clarify like (OpenJDK ID - kcr) > > exactly my point. when the majority of time is spent in the context of github (PR review etc) it might be confusing when one types `@jvos` and it's not found, or when within a PR there are references to both `jvos` and `johanvos` > > (see the very first comment in https://github.com/openjdk/jfx/pull/1388 ) Ah, I misunderstood Andy's comment. Yes, I'll update this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602297383 From kcr at openjdk.org Wed May 15 22:24:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:12:09 GMT, Phil Race wrote: >> README-code-reviews.md line 48: >> >>> 46: All code reviews must be done via a pull request submitted against this GitHub repo, [openjdk/jfx](https://github.com/openjdk/jfx). A JBS bug ID must exist before the pull request will be reviewed. See [CONTRIBUTING.md](CONTRIBUTING.md) for information on how to submit a pull request. >>> 47: >>> 48: All fixes must be reviewed by at least one reviewer with the "Reviewer" role (aka a "R"eviewer). We have a different code review threshold for different types of changes. If there is disagreement as to whether a fix is low-impact or high-impact, then it is considered high-impact. In other words we will always err on the side of quality by "rounding up" to the next higher category. The contributor can say whether they think something is low-impact or high-impact, but It is up to a Reviewer to confirm this. A Reviewer either adds a comment indicating that they think a single review is sufficient, or else issues the Skara `/reviewers 2` command requesting a second reviewer (a Reviewer can request more than 2 reviewers in some cases where a fix might be especially risky or cut across multiple functional areas). >> >> "but **It** is" -> it > > I think it worth noting that in skara syntax that isn't two people with the reviewer role. > And tell people what to use if that is what they intend - eg if I have it right It's `/reviewers 2 reviewers`, so I'll add that as an example and clarify that `/reviewers 2` is 2 with at least one reviewer. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602299262 From kcr at openjdk.org Wed May 15 22:24:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:11 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:04:19 GMT, Nir Lisker wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 48: > >> 46: All code reviews must be done via a pull request submitted against this GitHub repo, [openjdk/jfx](https://github.com/openjdk/jfx). A JBS bug ID must exist before the pull request will be reviewed. See [CONTRIBUTING.md](CONTRIBUTING.md) for information on how to submit a pull request. >> 47: >> 48: All fixes must be reviewed by at least one reviewer with the "Reviewer" role (aka a "R"eviewer). We have a different code review threshold for different types of changes. If there is disagreement as to whether a fix is low-impact or high-impact, then it is considered high-impact. In other words we will always err on the side of quality by "rounding up" to the next higher category. The contributor can say whether they think something is low-impact or high-impact, but It is up to a Reviewer to confirm this. A Reviewer either adds a comment indicating that they think a single review is sufficient, or else issues the Skara `/reviewers 2` command requesting a second reviewer (a Reviewer can request more than 2 reviewers in some cases where a fix might be especially risky or cut across multiple functional areas). > > About requesting reviews. I think that only some people can request reviews through GitHub, I never managed to do it on this repo, probably a matter of permissions. Might worth clarifying how this works. It's better to just add comments `@` mentioning who you want to do the review, since there isn't a way for most people to request a review from others. > README-code-reviews.md line 58: > >> 56: * Determine whether this needs 2 reviewers and whether it needs a CSR; issue the `/reviewers 2` or `/csr` command as needed >> 57: * If you want to indicate your approval, but still feel additional reviewers are needed, you may increase the number of reviewers (e.g., from 2 to 3) >> 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it > > Should a list of experts per area be made available somewhere? The Wiki has an old "code ownership" table that is out of date. Usually you get to know the experts only after they have reviewed your code a couple of times. That might be something to consider as a follow-on. > README-code-reviews.md line 60: > >> 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it >> 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have >> 60: > > Another thing to look out for is the targeting branch during rampdown. Should they all target master and then be backported as needed, or can some target the rampdown branch? Good idea. I'll add the bit about checking the target branch -- if the PR isn't a backport it should almost always target the master branch (there might be _very_ rare exception where a bug is specific to the stabilization branch). > README-code-reviews.md line 69: > >> 67: * Check whether there is an automated test; if not, ask for one, if it is feasible >> 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows >> 69: * If the PR source branch hasn't synced up from master in a long time, or if there is an upstream commit not in the source branch that might interfere with the PR, ask the PR author to merge the latest upstream master. > > This is the only bullet point with a period at the end. I'll fix it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602301589 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602301960 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602303525 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602310146 From kcr at openjdk.org Wed May 15 22:24:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:12 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:50:32 GMT, Andy Goryachev wrote: >> README-code-reviews.md line 60: >> >>> 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it >>> 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have >>> 60: >> >> I would add that it's a good idea to search for JBS issues similar/linked to the one being targeted. There are many unfound duplicates in JBS that arise only when searching, or at least closely linked ones (problems in `TableTreeView` often have "pseudo-duplicates" for `TreeView` and `TableView`, for example). >> >> I would explain (or link to where it is explained) when to close an issue a a duplicated vs. when to use the /add Skara command to bundle issues into the same fix. >> >> We might also find that the targeted issue is a regression of another issue. This is somewhat mentioned in the bullet point below "Consider the risk of regression". > > Second this, although I think the bulk of the work should fall on the author of the PR. This would probably be better in the CONTRIBUTING guidelines (for PR authors). Maybe as a follow-on, but I'll give it some thought. >> README-code-reviews.md line 66: >> >>> 64: * Focus first on substantive comments rather than stylistic comments >>> 65: * Consider the risk of regression >>> 66: * Consider any compatibility concerns >> >> This might be included in this point already, but one thing I sometimes miss is the inadvertent introduction of new API (that will have to be deprecated if missed). This can happen with `protected` methods, default `public` constructors (esp. if a non-API constructor is removed), or if a class is moved from a non-exported to an exported package (something that you can't see by looking at the area you're reviewing, you need to check the `module-info`, or more practically, look at the package names). > > I was wondering if there ought to be an unofficial checklist for things to look for? > As new people become "R"eviewers, I think there is a value in accumulating collective wisdom in a checklist. I like checklists. > ...inadvertent introduction of new API (that will have to be deprecated if missed) I think this is worth mentioning. > I was wondering if there ought to be an unofficial checklist for things to look for? That's sort of what this section is meant to be. As long as it doesn't get too verbose we could add additional things to look for. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602302685 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602306295 From kcr at openjdk.org Wed May 15 22:24:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:12 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: <9DHtGWaenwBZgu5-GlnaFVQrnEJsnv-LyC-vDvVFX4M=.f53b52e5-f99a-4b76-a905-030cf6153fc2@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> <9DHtGWaenwBZgu5-GlnaFVQrnEJsnv-LyC-vDvVFX4M=.f53b52e5-f99a-4b76-a905-030cf6153fc2@github.com> Message-ID: On Wed, 15 May 2024 20:23:37 GMT, Nir Lisker wrote: >> Isn't this automatic? Seems weird you could integrate without these passing. > >> or is it? :-) > > ![image](https://github.com/openjdk/jfx/assets/37422899/8daab7cf-f050-4964-b8a6-731666422293) > > Looks to me like it is... A passing GHA test run is neither necessary nor sufficient. It is an interesting data point. A PR can be integrated with a failing run as long as we understand why it failed. It is something for a reviewer to check and ask about if they suspect it points to a real problem. I'll reword this a little bit to make it clear. I'm sort of glad that GitHub / Azure chose today to break it. It is a great illustration of why we don't want it to be blocking. Btw, I filed https://bugs.openjdk.org/browse/JDK-8332328 to track the GHA failure. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602309862 From kcr at openjdk.org Wed May 15 22:24:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:13 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:08:05 GMT, John Hendrikx wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > README-code-reviews.md line 79: > >> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. >> 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. >> 79: * Verify the commit message. The Skara tooling adds a comment near the top of the PR with the commit message that will be used. You can add a summary to the commit message with the `/summary` command. You can add additional contributors with the `/contributor` command. Commands are issued by adding a comment to the PR that starts with a slash `/` character. > > The last sentence feels a bit out of place, as several places earlier in this document already mention slash commands. I'll remove it (I moved it from the CONTRIBUTING doc, and it does seem out of place). Actually as someone else commented, Skara will verify that the PR title and JBS bug match, so mostly this is about adding a summary and/or contributors if you want to. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602315921 From kcr at openjdk.org Wed May 15 22:24:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 15 May 2024 22:24:13 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 20:18:05 GMT, Phil Race wrote: >> This is out of scope for this PR, but it might be something to consider addressing in a follow-on enhancement. > > It should be made clear (somewhere, at some point) that it would be rare for a CSR to be completed and approved before starting work on the implementation because the spec. almost always evolves as the fix is developed. Yes, that is a good point. I'll file a follow-up to do that (since this section is otherwise unmodified from the current guidelines on the Wiki). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602318735 From andy.goryachev at oracle.com Wed May 15 22:41:45 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 15 May 2024 22:41:45 +0000 Subject: Proposal: Public InputMap (v2) In-Reply-To: References: Message-ID: Dear John: Thank you for a thoughtful response! I am a bit surprised - the point #1 you are trying to make is explicitly supported by the new API. The new API introduces a (fixed) number of priorities to the Controls' event handling specifically to address the issue you've raised earlier. Yes, it is done at the controls' level rather than at the event dispatching level as it was proposed in https://github.com/openjdk/jfx/pull/1266 - for two reasons: 1. doing so at the event dispatching level is a major API change, maybe that's why #1266 went nowhere 2. the only place where fx has this problem is with Controls, since they have to deal with multiple actors, as I explained in my response to Michael's. And the new API is not limited to key events, the priority scheme is extended to any event type. #2. Separation of Behavior and Skins. We went through this a number of times, so let me reiterate my points. Behavior is tied to a particular skin; changing a skin in a drastic way or changing the behavior in a drastic way is possible, if a) there is a need and b) both Skin and its Behavior are made sufficiently public. Alternatively, one must introduce an new API between Skin and its Behavior, which is possible for a particular skin, or a particular control, but I don't think is possible generally. Different skins may require different control surfaces, different gestures, completely different event handling... In any case, this problem I feel is outside of the scope of my proposal. #3. Rock solid primitives. I am all for it! Focus traversal - excellent idea! Let's discuss maybe in a separate thread? But as far as InputMap is concerned, it's a totally different area, out of scope for this proposal. And finally, I disagree with you about incremental changes and fixes. The value of the InputMap it brings to both application and skin developers cannot, I believe, be achieved by incremental steps. Is there something that the proposed APIs that makes it impossible to move forward? Thank you -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, May 15, 2024 at 14:34 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Public InputMap (v2) I can only second this. If anything, the proposal highlights several fundamental problems in current JavaFX by how it is trying to work around them. The work around works for one area (key events) but does not address similar problems for other events. The work around will also further cement these problems making them harder to address in the future. I'll reiterate what I think are more fundamental issues that should be addressed: 1. Behaviors/Skins/Controls should not be hijacking events for their own purposes before the user has their say in their handling. If the user is not consuming the event (at any level), only then should it fall back to defaults. The reason why it currently works this way is because the public infrastructure for event handling is being used by Skin and Behavior implementations; this infrastructure however by its nature is a first come first serve system (unlike listeners), which makes it risky to share with users unless measures are taken to ensure there are no visible side effects of this sharing. Effectively this also means Skins and Behaviors can *never* add a new event handler, or even a key mapping without risking breaking existing apps. Even consuming a new event in an existing handler, or changing its consumption pattern can cause breakage as it currently stands. 2. Separation of Behaviors and Skins. Even for complex controls this is possible, if there is a willingness to do so. This will open up far easier extension of the FX platform where the choice is not to either throw away all behavior and implement everything yourself, or hope you can sufficiently hack the existing skin (which were never designed for extension) to suit your needs. 3. Provide rock solid control primitives, and provide the infrastructure to build more complicated controls. I should be able to copy/paste any FX control, give it a new name, and then have it behave exactly as the original in all respects. This may mean opening up (or more likely, evaluating and partially redesigning) certain private API's (like focus traversal). I feel strongly that these would provide far more value currently, and, as these are all aspects that can't be addressed easily by 3rd parties or be worked around, only FX developers can solve these. As far as the proposal is concerned, I feel that it is taking a giant leap towards a perceived solution for an X/Y type problem. I think we should be making far smaller incremental changes and fixes, and seeing what those bring. This may eventually lead to an InputMap type system, but it could also lead to a place where the issue to provide it has become less urgent, giving us time to address other more fundamental problems. --John On 07/05/2024 10:44, Michael Strau? wrote: > Hi Andy! > > The updated proposal seems to be a slight refinement of the original > proposal, and I think most of the points raised in the previous > discussion still stand. > > As it is, I still think that this is an exceptionally large API > surface for what the feature can actually bring to the table. It's > overly specific in trying to solve problems for which general-purpose > APIs like event handlers can be extended to work just as well (and > open up many more use cases than just those of a bespoke control API). > > The fact that the API tries to fix a problem with the event system > itself (unpredictable invocation order) is a red flag. We should fix > this problem where it originates, which is the event API; crafting > workaround APIs in other parts of JavaFX doesn't seem to be the right > approach to me. This would also help to break the problem down into > more manageable chunks: improve the event system first, then see how > that influences the remaining problems that need to be solved. > > You provide several examples of what the InputMap API can do: > > > 1. Adding a new key mapping > > // creates a new key binding mapped to an external function > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> { > externalFunction(); > }); > > I don't see why this is needed. It doesn't seem to be easier than > using a plain old event handler, it's just different. > > > 2. Redefine an existing function > > // redefine function keeping existing key mappings > getInputMap().registerFunction(Tag.COPY, (control) -> customCopy()); > > If I want to change the meaning of the copy() method, can I not just > override the method and provide my own implementation? Plain old Java > seems to do the job. > > > 3. Map an existing function to a new binding > > // map a new key binding > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), Tag.COPY); > > Again, an event handler would do the job here. > > > 4. Obtain the default function > > // obtains the default function handler > FunctionHandler h = getInputMap().getDefaultFunction(Tag.COPY); > > If I override the copy() method to provide my own implementation, I > could also add a defaultCopy() method that calls the base > implementation. Then I can call both copy() and defaultCopy(). > (I don't know why I would want to do this, though.) > > > To summarize: the way I see it, your examples don't provide a > compelling reason why we need this new API. Given the size and > complexity of the proposal, I suggest to break the problem down into > more manageable parts, and solve the most fundamental issues first. At > the very least, the issue with event invocation ordering should be > solved in the event system. > > > > On Mon, Mar 11, 2024 at 4:22?PM Andy Goryachev > wrote: >> Dear JavaFX developers: >> >> >> >> Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were: >> >> >> >> desire for some static behavior to avoid the per-instance penalty >> clearer separation of concerns between controls, skins, and behaviors >> desire to have some sort of public API for behaviors >> need for addressing an issue with the event handler execution order between application and skins >> >> >> >> I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include: >> >> >> >> separation of SkinInputMap from the control's InputMap >> enabling static skin input maps for stateless behaviors >> explicit priority levels for event handlers and key mappings created by the application and by the skin >> >> >> >> The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls: >> >> >> >> complex popup-like controls: ComboBox, ColorPicker, DatePicker >> complex text input controls: PasswordField, TextArea, TextField >> control with a stateless behavior: TabPane >> >> >> >> as well as a brand new RichTextArea control being incubated [8]. >> >> >> >> Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. >> >> >> >> For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below. >> >> >> >> What do you think? >> >> -andy >> >> >> >> >> >> References >> >> >> >> [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md >> >> [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md >> >> [2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ >> >> [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395 >> >> [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 >> >> [5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior >> >> [6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md >> >> [7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html >> >> [8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed May 15 23:05:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 15 May 2024 23:05:28 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height Message-ID: The javadoc for `Region.getPrefHeight() / getPrefWidth()` incorrectly refers to `getPrefHeight(forWidth) / getPrefWidth(forHeight)` should be `prefHeight(forWidth) / prefWidth(forHeight)` - also converted these references to `{@link}`s. ------------- Commit messages: - 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height Changes: https://git.openjdk.org/jfx/pull/1456/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1456&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332251 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1456.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/jfx/pull/1456 From mhanl at openjdk.org Thu May 16 07:29:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 16 May 2024 07:29:13 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Mon, 6 May 2024 21:11:35 GMT, Martin Fox wrote: > I'll look into the Linux failure. The core EventLoop code passes an object into the application's leaveNestedEventLoop and expects to see that object returned from the applications's matching enterNestedEventLoop call. On Mac and Windows this object is passed through to glass as an argument on the stack. On Linux this value is handled as an application global. I suspect the Linux bookkeeping isn't robust enough to handle this case but it will take a bit to nail down the details. There is one additional change I made, which might be relevant for Linux: https://github.com/openjdk/jfx/pull/1324/files#diff-af779aafb50953f57cab2478dd220d0322592b60e92065cf658644866572b7e7R117 Worth to check. I remember that the code there was problematic to me. Otherwise this looks good. https://github.com/openjdk/jfx/pull/1324 also cleans up the unused return value which is allocated in the C++/Objective-C side, but never really used on the Java side. So might be worth to do at some point, but I would agree to do the minimal changes first. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2114266915 From jvos at openjdk.org Thu May 16 07:30:13 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 16 May 2024 07:30:13 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <-hRvDPtRdNHSNhO_U4D8hksvXb1ZtMxcpTNZz5iyxHY=.77f7dd6a-2faa-4b53-a043-663ad032818f@github.com> On Wed, 15 May 2024 19:39:10 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 66: >> >>> 64: * Focus first on substantive comments rather than stylistic comments >>> 65: * Consider the risk of regression >>> 66: * Consider any compatibility concerns >> >> regression and compatibility risks are probably the most important aspects of the code review from the "R"eviewer's perspective. Perhaps this should be emphasized somehow? > > That's a good idea. In the ideal world where we have tons of regression and compatibility tests, I would agree. Unfortunately, we are totally not there yet. Compared to other projects, the quality of tests in OpenJFX is good, but given the multitude of usage scenario's in client development, we would need much, much more tests before we can rely on them to detect regression. Therefore, the #1 point imho is that both the author (as Andy commented) and the reviewer have a real good understanding on what is happening. Every single change in a PR should be understood. The most dangerous things are "I don't understand why, but it seems to fail before and succeed after the patch". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602762164 From jvos at openjdk.org Thu May 16 07:33:13 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 16 May 2024 07:33:13 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 21:57:23 GMT, Kevin Rushforth wrote: >> CONTRIBUTING.md line 233: >> >>> 231: * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. >>> 232: >>> 233: New code should be formatted consistently in accordance with the above guidelines. However, please do not reformat existing code as part of a bug fix. The makes more changes for code reviewers to track and review, and can lead to merge conflicts. If you want to reformat a class, do that in a separate pull request (which will need its own unique JBS bug ID). >> >> "The makes more changes" ? I think you mean "This" not "The" >> >> I'm not sure about the last sentence, it seems to encourage reformatting fixes which are just noise most of the time. > > Yeah, that was a typo (which I didn't notice when copying the block from the other doc). I'll fix it. And I agree with your concern, so I'll remove the last sentence. I agree with the concern, but I still think it's much better to encourage developers to do formatting in a separate issue (or not at all) with all the required administration, than to sneak in a formatting change in a PR that has nothing to do with formatting. I prefer the noise to be completely isolated, so that it can be ignored easily, rather than being distracted by it in a PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602767101 From jhendrikx at openjdk.org Thu May 16 08:51:09 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 16 May 2024 08:51:09 GMT Subject: RFR: 8332313: Update code review guidelines In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Thu, 16 May 2024 07:30:31 GMT, Johan Vos wrote: >> Yeah, that was a typo (which I didn't notice when copying the block from the other doc). I'll fix it. And I agree with your concern, so I'll remove the last sentence. > > I agree with the concern, but I still think it's much better to encourage developers to do formatting in a separate issue (or not at all) with all the required administration, than to sneak in a formatting change in a PR that has nothing to do with formatting. I prefer the noise to be completely isolated, so that it can be ignored easily, rather than being distracted by it in a PR. I think this conflicts a bit with the previous statement ("don't worry too much about import order"). In my experience, when merging complex changes, import order changes are often the cause of conflicts. We also found that with many different committer preferences, the whole import block could change from one commit to the next, which will lead to a conflict if such a file is part of a backport. We solved this by simply mandating a single order for imports (alphabetical, no gaps, no star imports) and made the build fail when it was violated. The number of conflicts went down dramatically. This does require a one time import fix of the code base, which will also be a source of conflicts, but at least it will be in the usual area (imports) and should solve the problem once and for all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1602895839 From arapte at openjdk.org Thu May 16 10:04:07 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 16 May 2024 10:04:07 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height In-Reply-To: References: Message-ID: On Wed, 15 May 2024 23:01:30 GMT, Andy Goryachev wrote: > The javadoc for `Region.getPrefHeight() / getPrefWidth()` incorrectly refers to `getPrefHeight(forWidth) / getPrefWidth(forHeight)` > > should be > > `prefHeight(forWidth) / prefWidth(forHeight)` > > - also converted these references to `{@link}`s. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1212: > 1210: *

> 1211: * Defaults to the USE_COMPUTED_SIZE flag, which means that > 1212: * {@link #prefHeight(forWidth)} will return the region's internally 1. In this file, the documentation for other properties like minWidth, minHeight use `` For similarity I think we should keep `` or change others as well to `link`. 2. There are similar correction needed at four other places in this file. As we are touching this file, I think these can be corrected too. If modified then the issue summary would need a modification too. 1252: * getMaxWidth(forHeight) will return the region's internally 1256: * getMaxWidth(forHeight) to return the region's preferred width, 1281: * getMaxHeight(forWidth) will return the region's internally 1285: * getMaxHeight(forWidth) to return the region's preferred height 3. Similar mistakes are observed in the PopupControl.java file too. I leave it to you to correct those here or handle separately ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1456#discussion_r1603035540 From angorya at openjdk.org Thu May 16 14:58:29 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 14:58:29 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height [v2] In-Reply-To: References: Message-ID: <4lWohBVI78nhQX2Iu5ntCsQ6t6dfmInKbD2i-LL_XDE=.1526c1ac-5e2b-484b-9a13-1c66d72455e6@github.com> > The javadoc for `Region.getPrefHeight() / getPrefWidth()` incorrectly refers to `getPrefHeight(forWidth) / getPrefWidth(forHeight)` > > should be > > `prefHeight(forWidth) / prefWidth(forHeight)` > > - same issue is also fixed in `PopupControl`. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: popup control ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1456/files - new: https://git.openjdk.org/jfx/pull/1456/files/003e6cff..251fefb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1456&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1456&range=00-01 Stats: 36 lines in 2 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jfx/pull/1456.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/jfx/pull/1456 From angorya at openjdk.org Thu May 16 14:58:29 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 14:58:29 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height [v2] In-Reply-To: References: Message-ID: On Thu, 16 May 2024 10:01:05 GMT, Ambarish Rapte wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> popup control > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1212: > >> 1210: *

>> 1211: * Defaults to the USE_COMPUTED_SIZE flag, which means that >> 1212: * {@link #prefHeight(forWidth)} will return the region's internally > > 1. In this file, the documentation for other properties like minWidth, minHeight use `` > For similarity I think we should keep `` or change others as well to `link`. > > 2. There are similar correction needed at four other places in this file. As we are touching this file, I think these can be corrected too. If modified then the issue summary would need a modification too. > 1252: * getMaxWidth(forHeight) will return the region's internally > 1256: * getMaxWidth(forHeight) to return the region's preferred width, > 1281: * getMaxHeight(forWidth) will return the region's internally > 1285: * getMaxHeight(forWidth) to return the region's preferred height > > 3. Similar mistakes are observed in the PopupControl.java file too. I leave it to you to correct those here or handle separately thank you for pointing this out, I am going to revert back to `` and update `PopupControl`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1456#discussion_r1603530347 From kcr at openjdk.org Thu May 16 15:48:19 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 15:48:19 GMT Subject: RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Message-ID: It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. With this fix, the GHA test build now passes on all platforms. See the test results to verify this. Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. ------------- Commit messages: - 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Changes: https://git.openjdk.org/jfx/pull/1457/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332328 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1457.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1457/head:pull/1457 PR: https://git.openjdk.org/jfx/pull/1457 From angorya at openjdk.org Thu May 16 15:54:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 15:54:12 GMT Subject: RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: On Thu, 16 May 2024 15:42:05 GMT, Kevin Rushforth wrote: > It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. > > With this fix, the GHA test build now passes on all platforms. See the test results to verify this. > > Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. looks good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1457#pullrequestreview-2061224330 From kcr at openjdk.org Thu May 16 15:58:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 15:58:30 GMT Subject: Integrated: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: <6XbCxLacKkajBsZ-TU49rSJMjjyaifqiw6OKPLnMlDU=.51f60852-0f6c-4297-8157-a87d42497014@github.com> On Thu, 16 May 2024 15:42:05 GMT, Kevin Rushforth wrote: > It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. > > With this fix, the GHA test build now passes on all platforms. See the test results to verify this. > > Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. This pull request has now been integrated. Changeset: d7ab5518 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/d7ab55184f757a614f9fc8f191c3c5794a16cc88 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Upgrade GHA Linux build platform to Ubuntu 24.04 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1457 From arapte at openjdk.org Thu May 16 16:26:08 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 16 May 2024 16:26:08 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height [v2] In-Reply-To: <4lWohBVI78nhQX2Iu5ntCsQ6t6dfmInKbD2i-LL_XDE=.1526c1ac-5e2b-484b-9a13-1c66d72455e6@github.com> References: <4lWohBVI78nhQX2Iu5ntCsQ6t6dfmInKbD2i-LL_XDE=.1526c1ac-5e2b-484b-9a13-1c66d72455e6@github.com> Message-ID: On Thu, 16 May 2024 14:58:29 GMT, Andy Goryachev wrote: >> The javadoc for `Region.getPrefHeight() / getPrefWidth()` incorrectly refers to `getPrefHeight(forWidth) / getPrefWidth(forHeight)` >> >> should be >> >> `prefHeight(forWidth) / prefWidth(forHeight)` >> >> - same issue is also fixed in `PopupControl`. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > popup control Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1456#pullrequestreview-2061307814 From arapte at openjdk.org Thu May 16 16:26:09 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 16 May 2024 16:26:09 GMT Subject: RFR: 8332251: javadoc: incorrect reference in Region.getPrefWidth/Height [v2] In-Reply-To: References: Message-ID: <9OF0bq1RpezNxA-ImDn3PujZyZ5lx8-T2bLuPmgJeIY=.a6b5b198-d18f-4708-b3b7-9e2554a5c31a@github.com> On Thu, 16 May 2024 14:54:47 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1212: >> >>> 1210: *

>>> 1211: * Defaults to the USE_COMPUTED_SIZE flag, which means that >>> 1212: * {@link #prefHeight(forWidth)} will return the region's internally >> >> 1. In this file, the documentation for other properties like minWidth, minHeight use `` >> For similarity I think we should keep `` or change others as well to `link`. >> >> 2. There are similar correction needed at four other places in this file. As we are touching this file, I think these can be corrected too. If modified then the issue summary would need a modification too. >> 1252: * getMaxWidth(forHeight) will return the region's internally >> 1256: * getMaxWidth(forHeight) to return the region's preferred width, >> 1281: * getMaxHeight(forWidth) will return the region's internally >> 1285: * getMaxHeight(forWidth) to return the region's preferred height >> >> 3. Similar mistakes are observed in the PopupControl.java file too. I leave it to you to correct those here or handle separately > > thank you for pointing this out, I am going to revert back to `` and update `PopupControl`. Looks good, I recommend to update the summary, current summary is quite specific to Region / prefWidth/Height. A suggestion-> javadoc: incorrect method references in Region and PopupControl ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1456#discussion_r1603683364 From nlisker at openjdk.org Thu May 16 16:31:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 16 May 2024 16:31:08 GMT Subject: RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: On Thu, 16 May 2024 15:42:05 GMT, Kevin Rushforth wrote: > It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. > > With this fix, the GHA test build now passes on all platforms. See the test results to verify this. > > Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. Note that the Ubuntu 24 runner is in beta: https://github.com/actions/runner-images#available-images. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1457#issuecomment-2115686652 From martin at martinfox.com Thu May 16 16:34:35 2024 From: martin at martinfox.com (Martin Fox) Date: Thu, 16 May 2024 09:34:35 -0700 Subject: KeyCode in the javafx.scene.robot.Robot interface In-Reply-To: References: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> Message-ID: In another thread someone asked whether JavaFX could report which keyboard layout is currently active. I don?t think there?s any useful way of doing this. The Mac organizes layouts using language codes. There are five variants for German and 15 for English. The German variants are ABC-QWERTZ, Austrian, German, German-DIN-2137, and SwissGerman. The English variants are ABC, USExtended, ABC-India, Australian, British, British-PC, Canadian, Colemak, Dvorak, Dvorak-Left, DVORAK-QWERTYCMD, Dvorak-Right, Irish, US, and USInternational-PC. Linux organizes layouts using country codes. When the user searches for a layout they see display names based on language but under the hood it?s all organized by country. On my Ubuntu 22 system there are 10 variants for Great Britain, 25 for the United States, and 20 for Germany. On Windows the user configures some number of input languages and then adds keyboard layouts to each language. On my system I have one language (English) and inside it are four layouts (U.S., French, German, and Spanish). It?s easy to find the user?s current input language but there?s no documented way to retrieve information about the current layout. Folks have reverse-engineered this but I?ve resisted going down that rabbit hole (it involves digging around in the registry). Setting aside the more specialized layouts like Dvorak most of the variants within a given language or country differ in the way they handle dead keys or the position of punctuation and symbol characters. So the variants matter but can?t be reported in any consistent way across platforms. > On May 15, 2024, at 7:49?AM, Martin Fox wrote: > > Mark, > > You may already know this but before JavaFX 21 the Mac and Windows Robot code had some long-standing bugs with non-US keyboards. Linux is in better shape but you can encounter problems if the user has installed multiple layouts (I have a PR pending to fix that). That might explain some of the flakey behavior you?ve been seeing. Your approach might also invoke an unexpected dead key depending on what modifiers you?re probing. > > With one exception JavaFX doesn?t have any facility for querying the keyboard layout. It relies on the platform code to take in keyboard events and translate them to JavaFX events on the fly. The exception is the internal call Toolkit.getKeyCodeForChar which attempts to map from a character to a KeyCode and is used to match shortcuts specified as KeyCharacterCombinations. Unfortunately the current implementation on Mac and Linux can?t really be extended to cover the sort of testing you?re trying to do. > > (On any OS the keyboard machinery is designed to take a series of physical keystrokes and produce a series of characters. Attempting to go in the opposite direction is fraught with complications particularly for punctuation and symbols. It?s faster and more reliable to wait for the user to type something and record what happens. That?s how getKeyCodeForChar is implemented on the Mac; until the user types something it yields no results. Linux is currently buggy but the PR to fix it adopts the same approach as the Mac.) > > JavaFX needs a better framework for testing text entry and I?ve thought about how that might look. But my priorities might be different than yours. Based on the bugs I?ve seen the biggest issue is that developers only test on the platforms and layouts they use. Much of this is due to lack of awareness but it?s also a big hurdle to have to buy Mac, Windows, and Linux boxes and then manually switch between layouts to test. My ideal framework would be based on emulated keyboards so, say, a U.S. Windows developer could generate a key event stream that corresponds to a Spanish Mac layout. > > That approach wouldn?t involve sending platform events through the OS. Extending the Robot to make it easier to, say, target punctuation and symbols via platform events would be nice to have but not essential (IMHO). > > So, no, you?re not missing anything exposed or under the hood. The approach you?re taking is probably the best that can be done with the current API. > > Martin > >> On May 12, 2024, at 3:16?AM, Mark Raynsford wrote: >> >> Hello! >> >> I maintain a test harness for JavaFX applications: >> >> https://www.github.com/io7m-com/xoanon >> >> I expose an interface that uses the javafx.scene.robot.Robot >> interface internally, but I expose a slightly higher level >> API that allows for (amongst other things) typing text as strings >> on components rather than sending individual key codes. >> >> The problem I immediately run into is that KeyCodes are keyboard >> layout specific, and there doesn't appear to be any way to detect >> what keyboard layout is in use. If I, for example, send the KeyCode for >> the `@` symbol, I'll actually get `"` on some keyboard layouts. This >> can cause some types of tests to fail, even though the code is correct. >> >> Consider a test where an email address is typed into a text field, and >> then the form containing the field is checked to see if the text field >> accepted/rejected the text as being a valid email address. On some >> keyboard layouts, a test that sends the string "someone at example.com" >> will fail because what ends up in the text field is actually >> "someone"example.com". >> >> I provide a workaround for this: At the start of the test suite run, >> xoanon will send every KeyCode to a text field one at a time and see >> what character appeared in the text field as a result. It then builds a >> mapping between characters to KeyCodes, and it can then do the >> translations as necessary when running the rest of the test suite: >> >> https://github.com/io7m-com/xoanon?tab=readme-ov-file#keymap-generation >> >> Unfortunately, this is still rather flaky. This often seems to fail more >> or less at random for reasons that aren't clear to me. >> >> Is there some way the Robot interface could be extended to allow for >> typing strings? Failing that, is there some way JavaFX could advertise >> the underlying keyboard map? I feel like some underlying component must >> know the information I'm trying to infer, but it doesn't seem to be >> exposed anywhere that I've been able to find. >> >> -- >> Mark Raynsford | https://www.io7m.com > From kcr at openjdk.org Thu May 16 16:43:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 16:43:08 GMT Subject: RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: On Thu, 16 May 2024 15:42:05 GMT, Kevin Rushforth wrote: > It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. > > With this fix, the GHA test build now passes on all platforms. See the test results to verify this. > > Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. Hopefully we won't see any instability as a result. If we do, then we might need to figure out how to get gcc-13 back on Ubuntu 22.04. We should keep an eye out for any odd Linux failures. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1457#issuecomment-2115734798 From angorya at openjdk.org Thu May 16 16:48:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 16:48:22 GMT Subject: RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: On Thu, 16 May 2024 15:42:05 GMT, Kevin Rushforth wrote: > It looks like the list of packages available in the Ubuntu 22.04 GitHub Actions test runner no longer includes `gcc-13` as of yesterday. I didn't find any documentation to indicate that this was intentional, but now that Ubuntu 24.04 is available we can fix the problem by updating to that version. We will need to do this at some point anyway, so we might as well do it now. > > With this fix, the GHA test build now passes on all platforms. See the test results to verify this. > > Given that GHA builds are currently broken on Linux, and that this fix doesn't affect the product at all (just our GHA tests), I will integrate this as soon as it is approved by 1 Reviewer, as an exception to the usual requirement to wait for 24 hours. it's working for me - https://github.com/openjdk/jfx/pull/1374/checks?check_run_id=25062333595 Thank you for fixing the setup! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1457#issuecomment-2115745629 From angorya at openjdk.org Thu May 16 16:51:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 16:51:07 GMT Subject: RFR: 8332251: javadoc: incorrect method references in Region and PopupControl [v2] In-Reply-To: <9OF0bq1RpezNxA-ImDn3PujZyZ5lx8-T2bLuPmgJeIY=.a6b5b198-d18f-4708-b3b7-9e2554a5c31a@github.com> References: <9OF0bq1RpezNxA-ImDn3PujZyZ5lx8-T2bLuPmgJeIY=.a6b5b198-d18f-4708-b3b7-9e2554a5c31a@github.com> Message-ID: <84vWIn_-YAE-kgGbMtZpBrtrFRupOj8UH5I4FQ41L0E=.e8a8e773-8755-4b8d-9b5a-d39515423e97@github.com> On Thu, 16 May 2024 16:23:26 GMT, Ambarish Rapte wrote: >> thank you for pointing this out, I am going to revert back to `` and update `PopupControl`. > > Looks good, > I recommend to update the summary, current summary is quite specific to Region / prefWidth/Height. > > A suggestion-> > javadoc: incorrect method references in Region and PopupControl excellent suggestion! done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1456#discussion_r1603721091 From angorya at openjdk.org Thu May 16 17:07:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 17:07:07 GMT Subject: Integrated: 8332251: javadoc: incorrect method references in Region and PopupControl In-Reply-To: References: Message-ID: On Wed, 15 May 2024 23:01:30 GMT, Andy Goryachev wrote: > The javadoc for `Region.getPrefHeight() / getPrefWidth()` incorrectly refers to `getPrefHeight(forWidth) / getPrefWidth(forHeight)` > > should be > > `prefHeight(forWidth) / prefWidth(forHeight)` > > - same issue is also fixed in `PopupControl`. This pull request has now been integrated. Changeset: ebe36893 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/ebe36893dd609b3d9373a2cc2b294b2eb6d94523 Stats: 37 lines in 2 files changed: 0 ins; 0 del; 37 mod 8332251: javadoc: incorrect method references in Region and PopupControl Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1456 From angorya at openjdk.org Thu May 16 18:34:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 16 May 2024 18:34:31 GMT Subject: RFR: 8324327: ColorPicker shows a white rectangle on clicking on picker Message-ID: Root cause: premature 'return' from initialization code leaves the hover square visible, even when it should be hidden, as the case is when the color value is not present in the palette. - added unit tests ------------- Commit messages: - 8324327: ColorPicker shows a white rectangle on clicking on picker Changes: https://git.openjdk.org/jfx/pull/1458/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324327 Stats: 64 lines in 2 files changed: 52 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1458.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1458/head:pull/1458 PR: https://git.openjdk.org/jfx/pull/1458 From org.openjdk at io7m.com Thu May 16 18:58:45 2024 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 16 May 2024 18:58:45 +0000 Subject: KeyCode in the javafx.scene.robot.Robot interface In-Reply-To: References: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> Message-ID: <146b9323-2821-4464-a806-a05f1618a3b5@io7m.com> Hello! On 15/05/2024 14:49, Martin Fox wrote: > Mark, > > You may already know this but before JavaFX 21 the Mac and Windows Robot code had some long-standing bugs with non-US keyboards. Linux is in better shape but you can encounter problems if the user has installed multiple layouts (I have a PR pending to fix that). That might explain some of the flakey behavior you?ve been seeing. Your approach might also invoke an unexpected dead key depending on what modifiers you?re probing. Very possible. I use this base set of keycodes: https://github.com/io7m-com/xoanon/blob/ac7c9c900c7908c5760a74d6cf4056fe3ffb8e92/com.io7m.xoanon.commander/src/main/java/com/io7m/xoanon/commander/internal/XCCommander.java#L235 I iterate over each key in that set, sending that keycode to a text field. I then do the same for each keycode but with the shift key held. I don't doubt that it could cause havoc in some setups! > With one exception JavaFX doesn?t have any facility for querying the keyboard layout. It relies on the platform code to take in keyboard events and translate them to JavaFX events on the fly. The exception is the internal call Toolkit.getKeyCodeForChar which attempts to map from a character to a KeyCode and is used to match shortcuts specified as KeyCharacterCombinations. Unfortunately the current implementation on Mac and Linux can?t really be extended to cover the sort of testing you?re trying to do. Right. > JavaFX needs a better framework for testing text entry and I?ve thought about how that might look... In my case, I'm almost always testing whether some UI elements become enabled or disabled based on validation occurring on a text field of some kind. A recent case was checking to see if a text field correctly rejected input that didn't appear to be an email address. Typing '@' into the field was difficult to make reliable. :) -- Mark Raynsford | https://www.io7m.com From kcr at openjdk.org Thu May 16 19:45:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 19:45:15 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 14:49:26 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of the getViewportLength() The API changes look good. I left one minor wording suggestion on the API docs. The new behavior feels more consistent to me, so I have no concerns. I'll leave it to @johanvos and @andy-goryachev-oracle to formally review it. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1915: > 1913: > 1914: /** > 1915: * The length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. Suggested change: "Returns the length of the viewport ..." ------------- PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2061722236 PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1603939589 From kcr at openjdk.org Thu May 16 19:47:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 19:47:10 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> References: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> Message-ID: On Mon, 6 May 2024 23:14:11 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > vertical scrolling tests As a follow-up enhancement, we might consider extending this to TextArea and/or ScrollPane. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2116057386 From kcr at openjdk.org Thu May 16 19:54:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 19:54:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Tue, 14 May 2024 13:37:32 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Adjust javadoc of the getViewportLength() > > Ok, I've updated the CSR accrodingly together with Eduard. @FlorianKirmaier or @eduardsdv can one of you merge in the latest upstream master? The source branch for this PR is a few months (and 134 commits) behind master. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2116066312 From kcr at openjdk.org Thu May 16 22:28:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 22:28:28 GMT Subject: [jfx22u] RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Message-ID: <6Wv4TdvJ6WPO6tqPW6bvKUAacCS0590_ehc3GeDoylw=.42d88625-5ae1-49d8-8b44-90248f9872a7@github.com> Clean backport of Linux GHA fix to jfx22u (so we can get clean GHA runs for future 22u backports) ------------- Commit messages: - Backport d7ab55184f757a614f9fc8f191c3c5794a16cc88 Changes: https://git.openjdk.org/jfx22u/pull/29/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=29&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332328 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx22u/pull/29.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/29/head:pull/29 PR: https://git.openjdk.org/jfx22u/pull/29 From kcr at openjdk.org Thu May 16 22:36:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 16 May 2024 22:36:08 GMT Subject: [jfx22u] RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: <6Wv4TdvJ6WPO6tqPW6bvKUAacCS0590_ehc3GeDoylw=.42d88625-5ae1-49d8-8b44-90248f9872a7@github.com> References: <6Wv4TdvJ6WPO6tqPW6bvKUAacCS0590_ehc3GeDoylw=.42d88625-5ae1-49d8-8b44-90248f9872a7@github.com> Message-ID: On Thu, 16 May 2024 22:23:40 GMT, Kevin Rushforth wrote: > Clean backport of Linux GHA fix to jfx22u (so we can get clean GHA runs for future 22u backports) @johanvos Since this is a clean backport, it doesn't need to be reviewed, but it does need maintainer approval. It's not an urgent fix, but until it is integrated, all GHA runs in this repo will fail on Linux. ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/29#issuecomment-2116311432 From fkirmaier at openjdk.org Fri May 17 07:23:45 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 17 May 2024 07:23:45 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v7] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8323511-scrollbar-jump - JDK-8323511: Adjust javadoc of the getViewportLength() - JDK-8323511: Mage getViewportLength() public and use it instead of getBlockIncrement() - JDK-8323511: Use viewport length as block increment - JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible - JDK-8323511 reverted accidental indentation chang - JDK-8323511 Making the scrolled height consistent, when abvoe/below the scrollbar is clicked. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/645feee3..f16cff94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=05-06 Stats: 381640 lines in 7736 files changed: 219841 ins; 105079 del; 56720 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From fkirmaier at openjdk.org Fri May 17 07:28:44 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 17 May 2024 07:28:44 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/f16cff94..023613d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From duke at openjdk.org Fri May 17 07:28:48 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 17 May 2024 07:28:48 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v7] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 07:23:45 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8323511-scrollbar-jump > - JDK-8323511: Adjust javadoc of the getViewportLength() > - JDK-8323511: Mage getViewportLength() public and use it instead of getBlockIncrement() > - JDK-8323511: Use viewport length as block increment > - JDK-8323511: Fix scrolling when clicking the scrollbar track when only one cell is visible > - JDK-8323511 > reverted accidental indentation chang > - JDK-8323511 > Making the scrolled height consistent, when abvoe/below the scrollbar is clicked. I have merged the master into this branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2116920437 From duke at openjdk.org Fri May 17 07:28:48 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 17 May 2024 07:28:48 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Thu, 16 May 2024 19:36:00 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Adjust javadoc of the getViewportLength() > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1915: > >> 1913: >> 1914: /** >> 1915: * The length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. > > Suggested change: > > "Returns the length of the viewport ..." Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1604468249 From arapte at openjdk.org Fri May 17 08:10:07 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 17 May 2024 08:10:07 GMT Subject: RFR: 8324327: ColorPicker shows a white rectangle on clicking on picker In-Reply-To: References: Message-ID: On Thu, 16 May 2024 18:30:17 GMT, Andy Goryachev wrote: > Root cause: premature 'return' from initialization code leaves the hover square visible, even when it should be hidden, as the case is when the color value is not present in the palette. > > - added unit tests Fix looks good, I think a single reviewer is sufficient for this. But please do wait for a while, may be for a day before integrating. I do have an observation to share: Another way to look at the root cause of the issue is that the `hoverSquare`'s visible property is not initialized in the `ColorPalette` constructor. The `hoverSquare` should **not** be visible by default, so adding this `hoverSquare.setVisible(false);` to `ColorPalette` constructor also solves the problem. Compared to PR change, this would avoid setting the visible property of focusSquare to false repeatedly in scenario when user keeps selecting custom color repeatedly. Anyway the fix is good, approving. Shall re-approve if you make any change. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1458#pullrequestreview-2062612821 From arapte at openjdk.org Fri May 17 12:02:10 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 17 May 2024 12:02:10 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2] In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev wrote: >> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). > > 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 two additional commits since the last revision: > > - Merge branch 'master' into 8330590.prev.word > - 8330590 TextInputControl: previous word fails with Bhojpuri characters Fix looks good, providing minor comments. modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 1745: > 1743: } > 1744: > 1745: private static boolean isLetterOrDigit(String text, int ix, int len) { The `len` variable is unused in this method. modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 1751: > 1749: } else if (ix >= text.length()) { > 1750: return false; > 1751: } May be combine them into single if statement. Or may be remove the checks as this is a private method. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1444#pullrequestreview-2062693079 PR Review Comment: https://git.openjdk.org/jfx/pull/1444#discussion_r1604573811 PR Review Comment: https://git.openjdk.org/jfx/pull/1444#discussion_r1604573300 From kcr at openjdk.org Fri May 17 12:13:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 12:13:09 GMT Subject: [jfx22u] Integrated: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: <6Wv4TdvJ6WPO6tqPW6bvKUAacCS0590_ehc3GeDoylw=.42d88625-5ae1-49d8-8b44-90248f9872a7@github.com> References: <6Wv4TdvJ6WPO6tqPW6bvKUAacCS0590_ehc3GeDoylw=.42d88625-5ae1-49d8-8b44-90248f9872a7@github.com> Message-ID: On Thu, 16 May 2024 22:23:40 GMT, Kevin Rushforth wrote: > Clean backport of Linux GHA fix to jfx22u (so we can get clean GHA runs for future 22u backports) This pull request has now been integrated. Changeset: e7545c6c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/e7545c6c5bb375980922eac93edf8e6ee977e5b5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Upgrade GHA Linux build platform to Ubuntu 24.04 Backport-of: d7ab55184f757a614f9fc8f191c3c5794a16cc88 ------------- PR: https://git.openjdk.org/jfx22u/pull/29 From fkirmaier at openjdk.org Fri May 17 12:39:14 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 17 May 2024 12:39:14 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8322619: Add test > - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" > > This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. Sorry for creating the CSR, it was an accident. Now that Eduard has both created an alternative solution, but also has reviewed that this solution is correct, and provided an unit-test - I think this (or the other) PR is ready to move forwards. @kevinrushforth What do you think? This is still quite a fundamental bug which is probably quite prevalent, because when it happens it is really hard to notice it. But it probably happens more often than we think. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2117507318 From jhendrikx at openjdk.org Fri May 17 13:24:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 17 May 2024 13:24:07 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` Even though this fix is more intrusive, it does seem to address the root cause. Instead of cleaning dirty bits in many places where it is easy to miss one, it always occurs only exactly where needed (after painting completes) using a method that can't accidentally miss parts. At a minimum I think the tests that are part of this PR should be included in FX whichever fix ends up being integrated. A quick glance doesn't turn up anything unexpected. I'm only wondering if the code in `paintImpl` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2117594606 From duke at openjdk.org Fri May 17 13:49:11 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 17 May 2024 13:49:11 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Fri, 17 May 2024 13:21:36 GMT, John Hendrikx wrote: > At a minimum I think the tests that are part of this PR should be included in FX whichever fix ends up being integrated. The test has already been added to both PRs. > I'm only wondering if the code in ``paintImpl`` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again. Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful. I'm fine with each of them. What do the others think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2117646858 From kcr at openjdk.org Fri May 17 14:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:43 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements 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 20 additional commits since the last revision: - Wait for re-review if you've pushed a change addressing a substantive comment - Typo + remove sentence that invites reformatting PRs - Wording changes, added example of API addition - Formatting - Add item about checking the target branch - Remove trailing period from previous - Minor changes regarding syncing from upstream master - Clarify that GHA tests might fail for a reason unrelated to the PR - Fix typo "but It" --> "but it" - Remove bullet about checking the commit message (Skara already checks) - ... and 10 more: https://git.openjdk.org/jfx/compare/3f56e6c0...9cf7f920 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1455/files - new: https://git.openjdk.org/jfx/pull/1455/files/1de03ec7..9cf7f920 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=00-01 Stats: 51497 lines in 127 files changed: 26323 ins; 14206 del; 10968 mod Patch: https://git.openjdk.org/jfx/pull/1455.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1455/head:pull/1455 PR: https://git.openjdk.org/jfx/pull/1455 From kcr at openjdk.org Fri May 17 14:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:43 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Thu, 16 May 2024 08:48:14 GMT, John Hendrikx wrote: >> I agree with the concern, but I still think it's much better to encourage developers to do formatting in a separate issue (or not at all) with all the required administration, than to sneak in a formatting change in a PR that has nothing to do with formatting. I prefer the noise to be completely isolated, so that it can be ignored easily, rather than being distracted by it in a PR. > > I think this conflicts a bit with the previous statement ("don't worry too much about import order"). In my experience, when merging complex changes, import order changes are often the cause of conflicts. We also found that with many different committer preferences, the whole import block could change from one commit to the next, which will lead to a conflict if such a file is part of a backport. > > We solved this by simply mandating a single order for imports (alphabetical, no gaps, no star imports, followed by separate block for static imports with the same rules) and made the build fail when it was violated. The number of conflicts went down dramatically. This does require a one time import fix of the code base, which will also be a source of conflicts, but at least it will be in the usual area (imports) and should solve the problem once and for all. I removed the bit encouraging reformatting PRs (but left the "don't reformat existing code..." bit. As for the import order, this came up recently in Andy's PRs to remove unnecessary imports. I'll file a follow-on issue to evaluate whether we want to change our current policy. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605067813 From kcr at openjdk.org Fri May 17 14:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:43 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 21:57:55 GMT, Kevin Rushforth wrote: >> exactly my point. when the majority of time is spent in the context of github (PR review etc) it might be confusing when one types `@jvos` and it's not found, or when within a PR there are references to both `jvos` and `johanvos` >> >> (see the very first comment in https://github.com/openjdk/jfx/pull/1388 ) > > Ah, I misunderstood Andy's comment. Yes, I'll update this. fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605057420 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 22:05:46 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 60: >> >>> 58: * If you want an area expert to review a PR, indicate this in a comment of the form: `Reviewers: @PERSON1 @PERSON2`; the requested reviewers can indicate whether or not they plan to review it >>> 59: * If you want to ensure that you have the opportunity to review this PR yourself, add a comment of the form: `@PRAUTHOR Wait for me to review this PR`, optionally add any concerns you might have >>> 60: >> >> Another thing to look out for is the targeting branch during rampdown. Should they all target master and then be backported as needed, or can some target the rampdown branch? > > Good idea. I'll add the bit about checking the target branch -- if the PR isn't a backport it should almost always target the master branch (there might be _very_ rare exception where a bug is specific to the stabilization branch). fixed >> README-code-reviews.md line 69: >> >>> 67: * Check whether there is an automated test; if not, ask for one, if it is feasible >>> 68: * Make sure that the PR has executed the GHA tests and that they all pass; if they aren't being run, ask the PR author to enable GHA workflows >>> 69: * If the PR source branch hasn't synced up from master in a long time, or if there is an upstream commit not in the source branch that might interfere with the PR, ask the PR author to merge the latest upstream master. >> >> This is the only bullet point with a period at the end. > > I'll fix it. fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605062508 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605062271 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 22:10:12 GMT, Kevin Rushforth wrote: > > ...inadvertent introduction of new API (that will have to be deprecated if missed) > > I think this is worth mentioning. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605063298 From kcr at openjdk.org Fri May 17 14:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:43 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 21:58:46 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 14: >> >>> 12: ### Reviewers >>> 13: >>> 14: The [List of Reviewers](https://openjdk.java.net/census#openjfx) is on the OpenJDK Census. >> >> We use ".org" now, not ".java.net" > > Yes, I missed this. I'll update. fixed >> README-code-reviews.md line 40: >> >>> 38: ### 1. The Reviewer role for the OpenJFX Project >>> 39: >>> 40: We define a formal "Reviewer" role, similar to the JDK project. A [Reviewer](https://openjdk.java.net/census#openjfx) is responsible for reviewing code changes and helping to determine whether a change is suitable for including into OpenJFX. We expect Reviewers to feel responsible not just for their piece, but for the quality of the JavaFX library as a whole. In other words, the role of Reviewer is one of stewardship. See the following section for what constitutes a good review. >> >> (https://openjdk.java.net/census#openjfx) >> >> .org please >> >> BTW these very long source lines make it awkward to precisely identify the text I'm commenting on. > > I'll fix it. fixed >> README-code-reviews.md line 77: >> >>> 75: >>> 76: * All substantive feedback has been addressed, especially any objections from one with a Reviewer role. >>> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. >> >> One thing to add here (or hereabouts) is that if someone has commented on your review and requested changes that in almost all cases you should expect that they will want to return to review the results. So DO NOT push without letting earlier reviewers who made substantive comments re-review. > > I'll add something about this. fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605064310 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605064515 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605064857 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> <9DHtGWaenwBZgu5-GlnaFVQrnEJsnv-LyC-vDvVFX4M=.f53b52e5-f99a-4b76-a905-030cf6153fc2@github.com> Message-ID: On Wed, 15 May 2024 22:13:34 GMT, Kevin Rushforth wrote: >>> or is it? :-) >> >> ![image](https://github.com/openjdk/jfx/assets/37422899/8daab7cf-f050-4964-b8a6-731666422293) >> >> Looks to me like it is... > > A passing GHA test run is neither necessary nor sufficient. It is an interesting data point. A PR can be integrated with a failing run as long as we understand why it failed. It is something for a reviewer to check and ask about if they suspect it points to a real problem. I'll reword this a little bit to make it clear. I'm sort of glad that GitHub / Azure chose today to break it. It is a great illustration of why we don't want it to be blocking. > > Btw, I filed https://bugs.openjdk.org/browse/JDK-8332328 to track the GHA failure. I updated the wording slightly ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605062114 From kcr at openjdk.org Fri May 17 14:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:43 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <9sddGTwmk8zVf-TxGjwb7G5vIU034A4MG9uNf-dPB0g=.2ee2a76e-900f-4604-9bb9-226a8d36408b@github.com> On Wed, 15 May 2024 22:00:42 GMT, Kevin Rushforth wrote: >> I think it worth noting that in skara syntax that isn't two people with the reviewer role. >> And tell people what to use if that is what they intend - eg if I have it right > > It's `/reviewers 2 reviewers`, so I'll add that as an example and clarify that `/reviewers 2` is 2 with at least one reviewer. Fixed (both the example Phil asked for and the typo Nir noted) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605061762 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 18:30:06 GMT, Andy Goryachev 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 20 additional commits since the last revision: >> >> - Wait for re-review if you've pushed a change addressing a substantive comment >> - Typo + remove sentence that invites reformatting PRs >> - Wording changes, added example of API addition >> - Formatting >> - Add item about checking the target branch >> - Remove trailing period from previous >> - Minor changes regarding syncing from upstream master >> - Clarify that GHA tests might fail for a reason unrelated to the PR >> - Fix typo >> >> "but It" --> "but it" >> - Remove bullet about checking the commit message (Skara already checks) >> - ... and 10 more: https://git.openjdk.org/jfx/compare/3f56e6c0...9cf7f920 > > README-code-reviews.md line 78: > >> 76: * All substantive feedback has been addressed, especially any objections from one with a Reviewer role. >> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. >> 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends / or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. > > nit pick: 24 hours does not always equal to one business day. A long weekend may extend the waiting period to 96 hours, a "winter break" might span the whole week. fixed > README-code-reviews.md line 79: > >> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. >> 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends / or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. >> 79: * Double-check the commit message before you integrate. Skara will list it near the top of your PR. > > is this needed? SKARA makes sure that it matches the JBS title. removed bullet ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605060203 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605060466 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: <-hRvDPtRdNHSNhO_U4D8hksvXb1ZtMxcpTNZz5iyxHY=.77f7dd6a-2faa-4b53-a043-663ad032818f@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> <-hRvDPtRdNHSNhO_U4D8hksvXb1ZtMxcpTNZz5iyxHY=.77f7dd6a-2faa-4b53-a043-663ad032818f@github.com> Message-ID: On Thu, 16 May 2024 07:27:34 GMT, Johan Vos wrote: >> That's a good idea. > > In the ideal world where we have tons of regression and compatibility tests, I would agree. Unfortunately, we are totally not there yet. Compared to other projects, the quality of tests in OpenJFX is good, but given the multitude of usage scenario's in client development, we would need much, much more tests before we can rely on them to detect regression. > Therefore, the #1 point imho is that both the author (as Andy commented) and the reviewer have a real good understanding on what is happening. Every single change in a PR should be understood. The most dangerous things are "I don't understand why, but it seems to fail before and succeed after the patch". Yes, this a good point. I left the "make sure you understand..." bullet as the first, and moved the "Focus first on substantive comments" below the regression and compatibility bullets. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605059984 From kcr at openjdk.org Fri May 17 14:10:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:44 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 19:38:55 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 64: >> >>> 62: >>> 63: * Make sure you understand why there was an issue to begin with, and why/how the proposed PR solves the issue >>> 64: * Focus first on substantive comments rather than stylistic comments >> >> this is not as important as the next two. > > Agreed. I'll move this bullet down. fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605057721 From kcr at openjdk.org Fri May 17 14:10:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:10:45 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <2_8orytavb2AbHGAHFt8LSMYDeskkSK6cEhEes34itY=.6e26b7ba-58fa-464d-946a-b8812ae2471d@github.com> On Wed, 15 May 2024 22:18:24 GMT, Kevin Rushforth wrote: >> README-code-reviews.md line 79: >> >>> 77: * All Reviewers who have requested the chance to review have done so (or indicated that they are OK with it going in without their review). In rare cases a Project Lead may override this. >>> 78: * The PR has been "rfr" (as indicated by Skara) for at least 1 business day (24 hours), not including weekends or major holidays. This is to allow sufficient time for those reviewers who might be in other time zones the chance to review if they have concerns. This is measured from the time that Skara has most recently added the "rfr" label (for example, for a PR that was previously in Draft mode, wait for at least 24 hours after the PR has been taken out of Draft and marked "rfr"). In rare cases (e.g., a build breakage) a Reviewer might give the OK to integrate without waiting for 24 hours. >>> 79: * Verify the commit message. The Skara tooling adds a comment near the top of the PR with the commit message that will be used. You can add a summary to the commit message with the `/summary` command. You can add additional contributors with the `/contributor` command. Commands are issued by adding a comment to the PR that starts with a slash `/` character. >> >> The last sentence feels a bit out of place, as several places earlier in this document already mention slash commands. > > I'll remove it (I moved it from the CONTRIBUTING doc, and it does seem out of place). > > Actually as someone else commented, Skara will verify that the PR title and JBS bug match, so mostly this is about adding a summary and/or contributors if you want to. Removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605063652 From kcr at openjdk.org Fri May 17 14:41:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:41:08 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <4S_T2Vdkt-i1nrnLyMUeQcycwmr7ThMUB5mfVO5BpzQ=.0282a5be-879f-4f1a-8764-2fd74c4f77bc@github.com> On Fri, 17 May 2024 14:10:43 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > 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 20 additional commits since the last revision: > > - Wait for re-review if you've pushed a change addressing a substantive comment > - Typo + remove sentence that invites reformatting PRs > - Wording changes, added example of API addition > - Formatting > - Add item about checking the target branch > - Remove trailing period from previous > - Minor changes regarding syncing from upstream master > - Clarify that GHA tests might fail for a reason unrelated to the PR > - Fix typo > > "but It" --> "but it" > - Remove bullet about checking the commit message (Skara already checks) > - ... and 10 more: https://git.openjdk.org/jfx/compare/b855c59f...9cf7f920 I addressed most of the feedback. There are still one or two more items I might update for this PR, but I'll capture the rest in follow-up issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1455#issuecomment-2117754680 From martin at martinfox.com Fri May 17 14:47:33 2024 From: martin at martinfox.com (Martin Fox) Date: Fri, 17 May 2024 07:47:33 -0700 Subject: KeyCode in the javafx.scene.robot.Robot interface In-Reply-To: <146b9323-2821-4464-a806-a05f1618a3b5@io7m.com> References: <4bcaa7c9-a3c8-4c4d-8dc1-50ac45e5c43a@io7m.com> <146b9323-2821-4464-a806-a05f1618a3b5@io7m.com> Message-ID: <47C4A0AA-16B7-4D2E-A95B-68D55644DEA9@martinfox.com> Mark, > I iterate over each key in that set, sending that keycode to a text > field. I then do the same for each keycode but with the shift key held. > I don't doubt that it could cause havoc in some setups! On a German or Spanish layout on the Mac BACK_QUOTE will invoke a dead key and throw everything off. Dead keys are miscoded on the Mac but since they aren?t used while typing there hasn?t been much motivation to fix that. If sending a KeyCode generates an InputMethodEvent instead of a KeyEvent you hit a dead key. Send a SPACE to clear the dead key state. That will generate another InputMethodEvent and insert a character into the text control. > In my case, I'm almost always testing whether some UI elements become > enabled or disabled based on validation occurring on a text field of > some kind. A recent case was checking to see if a text field correctly > rejected input that didn't appear to be an email address. Typing '@' > into the field was difficult to make reliable. :) For this sort of testing you can build KeyEvents and fire them yourself. That would allow you to bypass a bunch of fraught areas of the Robot like incorrect focus or accidentally invoking input methods. The internal KeyEventFirer object in JavaFX takes this approach. It uses several internal API?s but illustrate the basics, like sending PRESSED/TYPED/RELEASED trios for KeyCodes that generate characters. I would not mix this approach with a Robot since you would lose control of the ordering of events. Martin From kcr at openjdk.org Fri May 17 14:55:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 17 May 2024 14:55:18 GMT Subject: RFR: 8332313: Update code review guidelines [v3] In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix typos ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1455/files - new: https://git.openjdk.org/jfx/pull/1455/files/9cf7f920..784475b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1455.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1455/head:pull/1455 PR: https://git.openjdk.org/jfx/pull/1455 From angorya at openjdk.org Fri May 17 15:07:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 15:07:10 GMT Subject: RFR: 8332313: Update code review guidelines [v3] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Fri, 17 May 2024 14:55:18 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos was going to comment on two spelling errors, but you fixed it. looks good, thank you for moving this doc to the main repo as a markdown file! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2063681694 From nlisker at openjdk.org Fri May 17 15:12:13 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 17 May 2024 15:12:13 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Fri, 17 May 2024 14:10:43 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > 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 20 additional commits since the last revision: > > - Wait for re-review if you've pushed a change addressing a substantive comment > - Typo + remove sentence that invites reformatting PRs > - Wording changes, added example of API addition > - Formatting > - Add item about checking the target branch > - Remove trailing period from previous > - Minor changes regarding syncing from upstream master > - Clarify that GHA tests might fail for a reason unrelated to the PR > - Fix typo > > "but It" --> "but it" > - Remove bullet about checking the commit message (Skara already checks) > - ... and 10 more: https://git.openjdk.org/jfx/compare/1b088e5b...9cf7f920 README-code-reviews.md line 69: > 67: * Carefully consider the risk of regression > 68: * Carefully consider any compatibility concerns > 69: * Check whether it adds any new public or protected API, even implicitly (such as a public method that overrides a protected method, or a class that is moved from a non-exported to an exported package); if it does, indicate that it needs a CSR I think that if it looks like an oversight (the author forgot about the default constructor), it's better to indicate that than to indicate that the PR needs a CSR. Maybe something like: "if it does and it doesn't look like an oversight, indicate that it needs a CSR" README-code-reviews.md line 72: > 70: * Focus first on substantive comments rather than stylistic comments > 71: * Check whether there is an automated test; if not, ask for one, if it is feasible > 72: * Make sure that the PR has executed the GitHub Actions (GHA) tests; if they aren't being run, ask the PR author to enable GHA workflows; if the test fails on some platforms, check whether it is a real bug (sometimes a job fails becau se of GHA infrastucture changes or we see a spurious GHA failure) becau se -> because ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605152176 PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605147892 From nlisker at openjdk.org Fri May 17 15:12:13 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 17 May 2024 15:12:13 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <2oXlSmu8WxsHQTtSvt35ZxVe7-sBxs3aRBEwzydZXzk=.c3089666-f33d-482a-aad2-1c281166ba4a@github.com> On Fri, 17 May 2024 14:58:41 GMT, Nir Lisker 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 20 additional commits since the last revision: >> >> - Wait for re-review if you've pushed a change addressing a substantive comment >> - Typo + remove sentence that invites reformatting PRs >> - Wording changes, added example of API addition >> - Formatting >> - Add item about checking the target branch >> - Remove trailing period from previous >> - Minor changes regarding syncing from upstream master >> - Clarify that GHA tests might fail for a reason unrelated to the PR >> - Fix typo >> >> "but It" --> "but it" >> - Remove bullet about checking the commit message (Skara already checks) >> - ... and 10 more: https://git.openjdk.org/jfx/compare/1b088e5b...9cf7f920 > > README-code-reviews.md line 72: > >> 70: * Focus first on substantive comments rather than stylistic comments >> 71: * Check whether there is an automated test; if not, ask for one, if it is feasible >> 72: * Make sure that the PR has executed the GitHub Actions (GHA) tests; if they aren't being run, ask the PR author to enable GHA workflows; if the test fails on some platforms, check whether it is a real bug (sometimes a job fails becau se of GHA infrastucture changes or we see a spurious GHA failure) > > becau se -> because Never mind, got simul-fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605160705 From mfox at openjdk.org Fri May 17 15:14:09 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 17 May 2024 15:14:09 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: On Wed, 15 May 2024 21:05:33 GMT, Andy Goryachev wrote: > In the context of the recent discussion on the mailing list, would it be possible to actually detect the keyboard layout? I answered this question in full on the mailing list but will provide a summary here. There's no documented way of doing this on Windows. The Mac organizes layouts based on language (for example, English), Linux organizes them based on country (so Australia, Great Britain, and the U.S. are all distinct). On all platforms there are more layouts than you think (the Mac has 5 German layouts and Linux has 20 Germany layouts) and there's no standard on how the variants are designated. > Another question - I recall on Windows there is a way to enter certain key using Alt codes. Does this method exist on Linux? I'm not that familiar with this feature but here's my understanding. The feature isn't universal but tied to the input method system you're using. With IBus you can press Shift+Ctrl+U followed by the Unicode value followed by Enter. But if you want to use an IME with JavaFX you have to use the obsolete XIM framework instead which doesn't support this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2117817006 From tsayao at openjdk.org Fri May 17 15:35:18 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 17 May 2024 15:35:18 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I got some requests to reopen it. So, reopening. Feedback is welcome. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2117857650 From angorya at openjdk.org Fri May 17 15:36:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 15:36:27 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v3] In-Reply-To: References: Message-ID: > This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). 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 branch 'master' into 8330590.prev.word - Merge branch 'master' into 8330590.prev.word - 8330590 TextInputControl: previous word fails with Bhojpuri characters ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1444/files - new: https://git.openjdk.org/jfx/pull/1444/files/97322b08..6d1ce647 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1444&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1444&range=01-02 Stats: 55843 lines in 214 files changed: 29325 ins; 14913 del; 11605 mod Patch: https://git.openjdk.org/jfx/pull/1444.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1444/head:pull/1444 PR: https://git.openjdk.org/jfx/pull/1444 From angorya at openjdk.org Fri May 17 15:36:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 15:36:28 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 08:45:43 GMT, Ambarish Rapte wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8330590.prev.word >> - 8330590 TextInputControl: previous word fails with Bhojpuri characters > > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 1745: > >> 1743: } >> 1744: >> 1745: private static boolean isLetterOrDigit(String text, int ix, int len) { > > The `len` variable is unused in this method. fixed, thank you > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 1751: > >> 1749: } else if (ix >= text.length()) { >> 1750: return false; >> 1751: } > > May be combine them into single if statement. > Or may be remove the checks as this is a private method. I prefer to keep one statement per line; the checks are needed here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1444#discussion_r1605201603 PR Review Comment: https://git.openjdk.org/jfx/pull/1444#discussion_r1605203032 From angorya at openjdk.org Fri May 17 16:48:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 16:48:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 07:28:44 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2063952224 From angorya at openjdk.org Fri May 17 17:21:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 17:21:05 GMT Subject: RFR: 8324327: ColorPicker shows a white rectangle on clicking on picker In-Reply-To: References: Message-ID: On Fri, 17 May 2024 08:07:58 GMT, Ambarish Rapte wrote: > `hoverSquare`'s visible property is not initialized in the `ColorPalette` constructor. thank you for reviewing, @arapte ! effectively, yes, and that's the issue I have fixed, by explicitly setting visibility in `setFocusedSquare()` (which is called from the constructor). I think this is a better fix because it fixes the logic in this method which may be applicable in other cases. Setting `false` to a boolean property which is already `false` has very little overhead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1458#issuecomment-2118045404 From arapte at openjdk.org Fri May 17 18:01:07 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 17 May 2024 18:01:07 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v3] In-Reply-To: References: Message-ID: <5fisbHYic_WxrFdev5jzbr95wyIipBhyGkmXQ6nkIAQ=.606418dc-5a32-491c-acdf-a91049eca16b@github.com> On Fri, 17 May 2024 15:36:27 GMT, Andy Goryachev wrote: >> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). > > 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 branch 'master' into 8330590.prev.word > - Merge branch 'master' into 8330590.prev.word > - 8330590 TextInputControl: previous word fails with Bhojpuri characters Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1444#pullrequestreview-2064091882 From kpk at openjdk.org Fri May 17 18:32:07 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 17 May 2024 18:32:07 GMT Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v3] In-Reply-To: References: Message-ID: <-P3q62PFThfNRKwFRhMHHLiK3Nfdhkw-_WwcjBf710E=.8a9370b0-7c33-4683-aadd-6f9e23b30c54@github.com> On Fri, 17 May 2024 15:36:27 GMT, Andy Goryachev wrote: >> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). > > 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 branch 'master' into 8330590.prev.word > - Merge branch 'master' into 8330590.prev.word > - 8330590 TextInputControl: previous word fails with Bhojpuri characters Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1444#pullrequestreview-2064142921 From duke at openjdk.org Fri May 17 19:13:15 2024 From: duke at openjdk.org (Glavo) Date: Fri, 17 May 2024 19:13:15 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I've built this PR and made it available to some HMCL users (https://github.com/HMCL-dev/HMCL/discussions/3050). I will also report back to you once I receive feedback. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2118224968 From angorya at openjdk.org Fri May 17 19:22:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 19:22:39 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: > ## ManualTestWindow > > This facility provides the base class for manual tests which displays the test instructions, > the UI under test, and the Pass/Fail buttons. > > Example: > > > public class ManualTestExample extends ManualTestWindow { > public ManualTestExample() { > super( > "Manual Test Example", > """ > Instructions: > 1. you will see a button named "Test" > 2. press the button > 3. verify that the button can be pressed""", > 400, 250 > ); > } > > public static void main(String[] args) throws Exception { > launch(args); > } > > @Override > protected Node createContent() { > return new Button("Test"); > } > } > > > Resulting application window: > > ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) > > Readme: > > https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md > > @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). > > Q: What other features can be added to the test window? > > Edit: the sources are left in their original place at the root of the project. 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: - Merge branch 'master' into 8319555.manual - Merge remote-tracking branch 'origin/master' into 8319555.manual - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual - removed example - cleanup - whitespace - extends application - works - . - sources moved back - ... and 5 more: https://git.openjdk.org/jfx/compare/80425dd9...e4c8d29a ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1413/files - new: https://git.openjdk.org/jfx/pull/1413/files/45e53102..e4c8d29a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1413&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1413&range=07-08 Stats: 55843 lines in 213 files changed: 29324 ins; 14913 del; 11606 mod Patch: https://git.openjdk.org/jfx/pull/1413.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1413/head:pull/1413 PR: https://git.openjdk.org/jfx/pull/1413 From angorya at openjdk.org Fri May 17 19:22:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 17 May 2024 19:22:40 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v8] In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024 18:10:32 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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 14 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - Merge branch 'master' into 8319555.manual > - ... and 4 more: https://git.openjdk.org/jfx/compare/315f18f8...45e53102 keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2118237515 From duke at openjdk.org Fri May 17 20:31:13 2024 From: duke at openjdk.org (leewyatt) Date: Fri, 17 May 2024 20:31:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 15:32:10 GMT, Thiago Milczarek Sayao wrote: > I got some requests to reopen it. So, reopening. > > Feedback is welcome. Thank you so much for reopening the PR. We truly appreciate your responsiveness and commitment to improving this project. Your efforts make a significant difference for many of us, especially developers from non-English speaking countries. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2118342373 From kcr at openjdk.org Sat May 18 14:14:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 18 May 2024 14:14:09 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: <-0QmzhYi3xK2bmES3ZKP36-bY3tFm3cEWK9rffOD3d4=.8e2fcb9d-ab08-4ba4-b21c-16e38c5073cc@github.com> On Fri, 17 May 2024 13:46:12 GMT, eduardsdv wrote: > > I'm only wondering if the code in `paintImpl` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again. > > Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful. > > I'm fine with each of them. What do the others think? I'd probably lean towards addressing this in a follow-up issue, if there turns out to be a need. @arapte can you look at this when you review it? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2118837167 From kcr at openjdk.org Sat May 18 14:16:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 18 May 2024 14:16:10 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 12:36:22 GMT, Florian Kirmaier wrote: > Sorry for creating the CSR, it was an accident. No problem. > Now that Eduard has both created an alternative solution, but also has reviewed that this solution is correct, and provided an unit-test - I think this (or the other) PR is ready to move forwards. > > @kevinrushforth What do you think? Yes, I've asked @arapte to be the primary reviewer on this. I'll leave it to his judgment as to which of the two approaches to take forward. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2118837579 From kcr at openjdk.org Sat May 18 14:27:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 18 May 2024 14:27:09 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: <-qPbV7_GkxZIRAgKUupIJqeAWxNCe4qUzzwF7mWFvog=.cb69fbd5-844e-4d5e-824c-886214849d1c@github.com> On Fri, 17 May 2024 15:02:14 GMT, Nir Lisker 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 20 additional commits since the last revision: >> >> - Wait for re-review if you've pushed a change addressing a substantive comment >> - Typo + remove sentence that invites reformatting PRs >> - Wording changes, added example of API addition >> - Formatting >> - Add item about checking the target branch >> - Remove trailing period from previous >> - Minor changes regarding syncing from upstream master >> - Clarify that GHA tests might fail for a reason unrelated to the PR >> - Fix typo >> >> "but It" --> "but it" >> - Remove bullet about checking the commit message (Skara already checks) >> - ... and 10 more: https://git.openjdk.org/jfx/compare/1a4c0fd4...9cf7f920 > > README-code-reviews.md line 69: > >> 67: * Carefully consider the risk of regression >> 68: * Carefully consider any compatibility concerns >> 69: * Check whether it adds any new public or protected API, even implicitly (such as a public method that overrides a protected method, or a class that is moved from a non-exported to an exported package); if it does, indicate that it needs a CSR > > I think that if it looks like an oversight (the author forgot about the default constructor), it's better to indicate that than to indicate that the PR needs a CSR. Maybe something like: > "if it does and it doesn't look like an oversight, indicate that it needs a CSR" We have by now cleaned up our public API to avoid classes with an implicit no-arg constructor, so the only way this situation could arise in the future is if someone adds a new public class, which needs a CSR anyway. I guess it could also happen if someone proposed to delete the no-arg constructor, but we don't allow deleting of non-terminally-deprecated API anyway. Maybe it's worth changing "adds any new" to "adds, removes, or modifies any"? Somewhat related, these guidelines don't address what to look for when reviewing new API; perhaps a follow-on issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605797980 From nlisker at openjdk.org Sat May 18 14:31:07 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 18 May 2024 14:31:07 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: <-qPbV7_GkxZIRAgKUupIJqeAWxNCe4qUzzwF7mWFvog=.cb69fbd5-844e-4d5e-824c-886214849d1c@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> <-qPbV7_GkxZIRAgKUupIJqeAWxNCe4qUzzwF7mWFvog=.cb69fbd5-844e-4d5e-824c-886214849d1c@github.com> Message-ID: On Sat, 18 May 2024 14:24:49 GMT, Kevin Rushforth wrote: > Maybe it's worth changing "adds any new" to "adds, removes, or modifies any"? This looks like a good idea. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605798488 From tsayao at openjdk.org Mon May 20 13:06:17 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 20 May 2024 13:06:17 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: <7CQoAdio4NNqAvgXxtIy6526e6iwGfM7gdNwluV0pLM=.fb234f42-6a24-4138-8da5-6b334920f18f@github.com> On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 There's a pending change request that I think it's not needed anymore since I rolled back the changes on the InputMethod interface. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2120421037 From angorya at openjdk.org Mon May 20 14:55:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 20 May 2024 14:55:08 GMT Subject: Integrated: 8324327: ColorPicker shows a white rectangle on clicking on picker In-Reply-To: References: Message-ID: On Thu, 16 May 2024 18:30:17 GMT, Andy Goryachev wrote: > Root cause: premature 'return' from initialization code leaves the hover square visible, even when it should be hidden, as the case is when the color value is not present in the palette. > > - added unit tests This pull request has now been integrated. Changeset: 9dc4aa23 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/9dc4aa2341581d730c9d721e91ac0da081ffddcc Stats: 64 lines in 2 files changed: 52 ins; 6 del; 6 mod 8324327: ColorPicker shows a white rectangle on clicking on picker Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1458 From angorya at openjdk.org Mon May 20 14:58:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 20 May 2024 14:58:14 GMT Subject: Integrated: 8330590: TextInputControl: previous word fails with Bhojpuri characters In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024 19:44:28 GMT, Andy Goryachev wrote: > This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int). This pull request has now been integrated. Changeset: b5fe3622 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b5fe362286056e516be1d26f5d1cdda12eb20a4c Stats: 39 lines in 2 files changed: 36 ins; 1 del; 2 mod 8330590: TextInputControl: previous word fails with Bhojpuri characters Reviewed-by: kpk, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1444 From kcr at openjdk.org Mon May 20 20:53:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 20 May 2024 20:53:12 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: <7CQoAdio4NNqAvgXxtIy6526e6iwGfM7gdNwluV0pLM=.fb234f42-6a24-4138-8da5-6b334920f18f@github.com> References: <7CQoAdio4NNqAvgXxtIy6526e6iwGfM7gdNwluV0pLM=.fb234f42-6a24-4138-8da5-6b334920f18f@github.com> Message-ID: <2D87TUnPyEBQucfokbpU0I8MuIHIjE-NEwY4SvdwWPk=.8867ae91-b9b2-4659-991d-5b6b5ae5f0f4@github.com> On Mon, 20 May 2024 13:03:24 GMT, Thiago Milczarek Sayao wrote: > There's a pending change request that I think it's not needed anymore since I rolled back the changes on the InputMethod interface. That's correct, given that this no longer has any public API. I'll try dismissing that review and see if that gets rid of the "changes requested" notification. If it doesn't, please ignore that request. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2121185238 From kcr at openjdk.org Mon May 20 21:03:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 20 May 2024 21:03:07 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: <7LjY-L_C524gn6wWz8zJYWbzRQKZNz2SxKK8QFcLYN8=.f17c8e93-dc9b-4c76-878a-39bcdbc7768f@github.com> Message-ID: On Fri, 8 Mar 2024 16:39:56 GMT, Marius Hanl wrote: >> This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. >> >> Also, if this fixed [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425), then that bug should be closed as a duplicate of this one. >> >> @lukostyra @arapte can you also review this? > >> This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. > > I thought about this as well but could not find any problem at least on Windows. > If we want to be perfectly safe, we may still want to set the flag when `sizeToScene()` is called. What do you think? > > I used the following code to test this, and it didn't matter when `sizeToScene()` was called: > > > @Override > public void start(Stage primaryStage) throws Exception { > StackPane root = new StackPane(); > Button wss = new Button("Wss"); > wss.setPrefSize(50, 50); > root.getChildren().add(wss); > > Scene scene = new Scene(root); > > Stage stage = new Stage(); > stage.setWidth(500); > stage.setMaximized(true); > stage.sizeToScene(); > stage.setScene(scene); > stage.show(); > } @Maran23 I think this is pretty close to being ready to go in. At a minimum, you will need to merge master and then fix the test so that it will compile, and then create a CSR with the updated specification (I can help with that if needed). My only other suggestion was around additional tests that might be useful, but they could be done as a follow-on fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2121199537 From kcr at openjdk.org Mon May 20 23:32:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 20 May 2024 23:32:08 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> References: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> Message-ID: On Mon, 6 May 2024 23:14:11 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > vertical scrolling tests Looks good. I left one comment (on a comment line) that applies to all 4 controls. I'll reapprove if you make the suggested change. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 933: > 931: } > 932: > 933: // TODO not necessary with the new InputMap V2 I recommend removing this comment. There is no public "InputMap" API in JavaFX (and this would be just one of many things that might change if an when we have such a feature). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1393#pullrequestreview-2067087621 PR Review Comment: https://git.openjdk.org/jfx/pull/1393#discussion_r1607318160 From angorya at openjdk.org Mon May 20 23:37:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 20 May 2024 23:37:22 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v8] In-Reply-To: References: Message-ID: <27p-K0383gfmtLA0CQgxDbJieUMA9hBKv8P7KoDdBVQ=.3d46ea5e-085a-4a38-9cd7-95fcf9a3befd@github.com> > Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. > > **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > public void verticalUnitScroll(boolean down); > > > Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. 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 19 additional commits since the last revision: - review comments - Merge branch 'master' into 8313138.horizontal - vertical scrolling tests - added vertical scrolling - Merge branch 'master' into 8313138.horizontal - tests - cleanup - node orientation - Merge remote-tracking branch 'origin/master' into 8313138.horizontal - table view behavior - ... and 9 more: https://git.openjdk.org/jfx/compare/8b19413b...5ec3c27e ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1393/files - new: https://git.openjdk.org/jfx/pull/1393/files/eeaa8d91..5ec3c27e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=06-07 Stats: 54171 lines in 177 files changed: 28150 ins; 14565 del; 11456 mod Patch: https://git.openjdk.org/jfx/pull/1393.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1393/head:pull/1393 PR: https://git.openjdk.org/jfx/pull/1393 From angorya at openjdk.org Mon May 20 23:37:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 20 May 2024 23:37:22 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v7] In-Reply-To: References: <78-ddGH2rvLn6nwPojBZc8V9N5S8zpFnkJfGiohQVuw=.22676c86-9a7b-4359-97d0-006bdcf03594@github.com> Message-ID: On Mon, 20 May 2024 21:40:30 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> vertical scrolling tests > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 933: > >> 931: } >> 932: >> 933: // TODO not necessary with the new InputMap V2 > > I recommend removing this comment. There is no public "InputMap" API in JavaFX (and this would be just one of many things that might change if an when we have such a feature). removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1393#discussion_r1607401687 From hmeda at openjdk.org Tue May 21 06:39:37 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 21 May 2024 06:39:37 GMT Subject: [jfx22u] RFR: 8331748: Update libxml2 to 2.12.6 Message-ID: <9eBuoNm5e7zqAS2yUSRddGwuAKazLE-S9og6Z1VI00Y=.f9765d0f-0447-4f5a-9a82-cccd3e453d48@github.com> Clean backport ------------- Commit messages: - Backport 97b1402501983f121f75c24a510f466837fa2ecc Changes: https://git.openjdk.org/jfx22u/pull/30/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=30&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331748 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod Patch: https://git.openjdk.org/jfx22u/pull/30.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/30/head:pull/30 PR: https://git.openjdk.org/jfx22u/pull/30 From hmeda at openjdk.org Tue May 21 06:40:38 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 21 May 2024 06:40:38 GMT Subject: [jfx22u] RFR: 8329011: Update SQLite to 3.45.3 Message-ID: Clean Backport ------------- Commit messages: - Backport 581e3a70a45a550a97e391e06735f4837336ada8 Changes: https://git.openjdk.org/jfx22u/pull/31/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=31&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329011 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod Patch: https://git.openjdk.org/jfx22u/pull/31.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/31/head:pull/31 PR: https://git.openjdk.org/jfx22u/pull/31 From javafx at ivoryemr.co.za Tue May 21 07:09:44 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Tue, 21 May 2024 09:09:44 +0200 Subject: Touch events are not dispatched after upgrade to JavaFX 17 In-Reply-To: References: Message-ID: Hi All Can JDK-8289115 (Touch events are not dispatched after upgrade to JavaFX 17) please get some attention again for the next release. Thanks, regards Jurgen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmeda at openjdk.org Tue May 21 08:26:10 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 21 May 2024 08:26:10 GMT Subject: [jfx22u] Integrated: 8331748: Update libxml2 to 2.12.6 In-Reply-To: <9eBuoNm5e7zqAS2yUSRddGwuAKazLE-S9og6Z1VI00Y=.f9765d0f-0447-4f5a-9a82-cccd3e453d48@github.com> References: <9eBuoNm5e7zqAS2yUSRddGwuAKazLE-S9og6Z1VI00Y=.f9765d0f-0447-4f5a-9a82-cccd3e453d48@github.com> Message-ID: On Tue, 21 May 2024 06:34:22 GMT, Hima Bindu Meda wrote: > Clean backport This pull request has now been integrated. Changeset: 8cdc502f Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/8cdc502f44b1046780913afe8d4157a521cb2f52 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod 8331748: Update libxml2 to 2.12.6 Backport-of: 97b1402501983f121f75c24a510f466837fa2ecc ------------- PR: https://git.openjdk.org/jfx22u/pull/30 From hmeda at openjdk.org Tue May 21 08:26:10 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 21 May 2024 08:26:10 GMT Subject: [jfx22u] Integrated: 8329011: Update SQLite to 3.45.3 In-Reply-To: References: Message-ID: On Tue, 21 May 2024 06:35:26 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: c0a15b7f Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/c0a15b7f9bde343c686a8ed545f8da16dcaf5d87 Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod 8329011: Update SQLite to 3.45.3 Backport-of: 581e3a70a45a550a97e391e06735f4837336ada8 ------------- PR: https://git.openjdk.org/jfx22u/pull/31 From kcr at openjdk.org Tue May 21 12:17:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 May 2024 12:17:15 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v8] In-Reply-To: <27p-K0383gfmtLA0CQgxDbJieUMA9hBKv8P7KoDdBVQ=.3d46ea5e-085a-4a38-9cd7-95fcf9a3befd@github.com> References: <27p-K0383gfmtLA0CQgxDbJieUMA9hBKv8P7KoDdBVQ=.3d46ea5e-085a-4a38-9cd7-95fcf9a3befd@github.com> Message-ID: On Mon, 20 May 2024 23:37:22 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > 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 19 additional commits since the last revision: > > - review comments > - Merge branch 'master' into 8313138.horizontal > - vertical scrolling tests > - added vertical scrolling > - Merge branch 'master' into 8313138.horizontal > - tests > - cleanup > - node orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - table view behavior > - ... and 9 more: https://git.openjdk.org/jfx/compare/0a0a3838...5ec3c27e Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1393#pullrequestreview-2068466846 From arapte at openjdk.org Tue May 21 13:35:13 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 21 May 2024 13:35:13 GMT Subject: RFR: 8313138: Scrollbar Keyboard enhancement [v8] In-Reply-To: <27p-K0383gfmtLA0CQgxDbJieUMA9hBKv8P7KoDdBVQ=.3d46ea5e-085a-4a38-9cd7-95fcf9a3befd@github.com> References: <27p-K0383gfmtLA0CQgxDbJieUMA9hBKv8P7KoDdBVQ=.3d46ea5e-085a-4a38-9cd7-95fcf9a3befd@github.com> Message-ID: <4wLLBmyZFkmaQHgJpPIS_Z23KSI7Ld5CNLF3WcIWPeI=.2da62a83-22b4-40d8-b9cd-ccef4b5d047b@github.com> On Mon, 20 May 2024 23:37:22 GMT, Andy Goryachev wrote: >> Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to >> >> - ListView >> - TreeView >> - TableView >> - TreeTableView >> >> to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. >> >> **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** >> >> As far as I can tell, these key combinations do not interfere with editing. >> >> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like >> >> >> public void horizontalUnitScroll(boolean right); >> public void verticalUnitScroll(boolean down); >> >> >> Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior >> >> Note: >> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. > > 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 19 additional commits since the last revision: > > - review comments > - Merge branch 'master' into 8313138.horizontal > - vertical scrolling tests > - added vertical scrolling > - Merge branch 'master' into 8313138.horizontal > - tests > - cleanup > - node orientation > - Merge remote-tracking branch 'origin/master' into 8313138.horizontal > - table view behavior > - ... and 9 more: https://git.openjdk.org/jfx/compare/b36355cd...5ec3c27e Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1393#pullrequestreview-2068661942 From mstrauss at openjdk.org Tue May 21 14:31:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 21 May 2024 14:31:30 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ Message-ID: This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): - const bool isDirect = true; + const bool isDirect = IsTouchEvent(); `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; ------------- Commit messages: - Fixed stylus detection Changes: https://git.openjdk.org/jfx/pull/1459/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1459&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289115 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1459.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1459/head:pull/1459 PR: https://git.openjdk.org/jfx/pull/1459 From kcr at openjdk.org Tue May 21 21:58:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 May 2024 21:58:13 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 07:28:44 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1918: > 1916: * Returns the length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. > 1917: * For a vertical flow, this corresponds to the height and for a horizontal flow to the width of the clip view, > 1918: * but it does not necessarily have to be the same value. @johanvos added a question in the CSR about this last part: > I understand and agree with the goal behind this. > > I'm a bit confused though about the following: "...but it does not necessarily have to be the same value." -> can you elaborate a bit about this? I share this concern. I think that removing that last clause and putting a period after "clip view" is probably the best. Johan: what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1608994568 From kcr at openjdk.org Tue May 21 22:32:21 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 May 2024 22:32:21 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Clarify need for CSR when API is modified or removed as well as added ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1455/files - new: https://git.openjdk.org/jfx/pull/1455/files/784475b0..7725881b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1455&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1455.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1455/head:pull/1455 PR: https://git.openjdk.org/jfx/pull/1455 From angorya at openjdk.org Tue May 21 22:38:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 21 May 2024 22:38:14 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2069743281 From kcr at openjdk.org Tue May 21 22:38:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 May 2024 22:38:14 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added I filed the following follow-on bug to address and pending items: [JDK-8332642](https://bugs.openjdk.org/browse/JDK-8332642): Additional improvements to contribution and code review guidelines I think I have addressed all of the feedback so far, either by updating the docs or by adding an item to JDK-8332642. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1455#issuecomment-2123544298 From kcr at openjdk.org Tue May 21 22:38:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 21 May 2024 22:38:14 GMT Subject: RFR: 8332313: Update code review guidelines [v2] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> <-qPbV7_GkxZIRAgKUupIJqeAWxNCe4qUzzwF7mWFvog=.cb69fbd5-844e-4d5e-824c-886214849d1c@github.com> Message-ID: On Sat, 18 May 2024 14:28:31 GMT, Nir Lisker wrote: >> We have by now cleaned up our public API to avoid classes with an implicit no-arg constructor, so the only way this situation could arise in the future is if someone adds a new public class, which needs a CSR anyway. >> >> I guess it could also happen if someone proposed to delete the no-arg constructor, but we don't allow deleting of non-terminally-deprecated API anyway. Maybe it's worth changing "adds any new" to "adds, removes, or modifies any"? >> >> Somewhat related, these guidelines don't address what to look for when reviewing new API; perhaps a follow-on issue. > >> Maybe it's worth changing "adds any new" to "adds, removes, or modifies any"? > > This looks like a good idea. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1609019119 From nlisker at openjdk.org Wed May 22 00:42:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 22 May 2024 00:42:08 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2069892902 From jvos at openjdk.org Wed May 22 06:42:12 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 May 2024 06:42:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 21:55:30 GMT, Kevin Rushforth wrote: > @johanvos added a question in the CSR about this last part: > > > I understand and agree with the goal behind this. > > I'm a bit confused though about the following: "...but it does not necessarily have to be the same value." -> can you elaborate a bit about this? > > I share this concern. I think that removing that last clause and putting a period after "clip view" is probably the best. > > Johan: what do you think? I agree that removing that clause is probably best to avoid confusion. Having open-ended suggestions in javadoc can lead to broad speculation, so I think it either should be explained (like you did in the CSR issue with the rubberband effect example) or removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1609371360 From mstrauss at openjdk.org Wed May 22 08:01:08 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 22 May 2024 08:01:08 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? wrote: > This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; @jperedadnr Maybe you could test this PR with the pen digitizer that you used for #394 to ensure that this change doesn't introduce yet another regression. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124119824 From jpereda at openjdk.org Wed May 22 08:13:07 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 22 May 2024 08:13:07 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? wrote: > This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; Yes, I'll do that, I still have it around. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124142803 From duke at openjdk.org Wed May 22 08:39:12 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 22 May 2024 08:39:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 06:39:18 GMT, Johan Vos wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1918: >> >>> 1916: * Returns the length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. >>> 1917: * For a vertical flow, this corresponds to the height and for a horizontal flow to the width of the clip view, >>> 1918: * but it does not necessarily have to be the same value. >> >> @johanvos added a question in the CSR about this last part: >> >>> I understand and agree with the goal behind this. >>> >>> I'm a bit confused though about the following: "...but it does not necessarily have to be the same value." -> can you elaborate a bit about this? >> >> I share this concern. I think that removing that last clause and putting a period after "clip view" is probably the best. >> >> Johan: what do you think? > >> @johanvos added a question in the CSR about this last part: >> >> > I understand and agree with the goal behind this. >> > I'm a bit confused though about the following: "...but it does not necessarily have to be the same value." -> can you elaborate a bit about this? >> >> I share this concern. I think that removing that last clause and putting a period after "clip view" is probably the best. >> >> Johan: what do you think? > > I agree that removing that clause is probably best to avoid confusion. Having open-ended suggestions in javadoc can lead to broad speculation, so I think it either should be explained (like you did in the CSR issue with the rubberband effect example) or removed. We should probably also avoid the word "corresponds". /** * Returns the length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. * For a vertical flow this is based on the height and for a horizontal flow on the width of the clip view. * * @return the viewport length in pixels * @since 23 */ The text explains that depending on the orientation of the view height or width is used in the calculation and the word "based" makes it clear that the value can differ from the respective size of the view. This version looks good to me. If it is fine for you too, I would check it in. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1609542246 From jhendrikx at openjdk.org Wed May 22 10:42:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 22 May 2024 10:42:08 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2070822120 From kcr at openjdk.org Wed May 22 12:12:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 May 2024 12:12:10 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added @johanvos Do you want to review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1455#issuecomment-2124636248 From kcr at openjdk.org Wed May 22 12:20:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 May 2024 12:20:06 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Wed, 22 May 2024 08:10:16 GMT, Jose Pereda wrote: >> This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): >> >> - const bool isDirect = true; >> + const bool isDirect = IsTouchEvent(); >> >> >> `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages >> >> I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: >> _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ >> >> But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. >> I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). >> >> My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: >> >> const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; > > Yes, I'll do that, I still have it around. Reviewer: @jperedadnr ------------- PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124650489 From kcr at openjdk.org Wed May 22 12:21:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 May 2024 12:21:10 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 08:36:22 GMT, eduardsdv wrote: >>> @johanvos added a question in the CSR about this last part: >>> >>> > I understand and agree with the goal behind this. >>> > I'm a bit confused though about the following: "...but it does not necessarily have to be the same value." -> can you elaborate a bit about this? >>> >>> I share this concern. I think that removing that last clause and putting a period after "clip view" is probably the best. >>> >>> Johan: what do you think? >> >> I agree that removing that clause is probably best to avoid confusion. Having open-ended suggestions in javadoc can lead to broad speculation, so I think it either should be explained (like you did in the CSR issue with the rubberband effect example) or removed. > > We should probably also avoid the word "corresponds". > > > /** > * Returns the length of the viewport portion of the {@code VirtualFlow} as computed during the layout pass. > * For a vertical flow this is based on the height and for a horizontal flow on the width of the clip view. > * > * @return the viewport length in pixels > * @since 23 > */ > > The text explains that depending on the orientation of the view height or width is used in the calculation and the word "based" makes it clear that the value can differ from the respective size of the view. > > This version looks good to me. If it is fine for you too, I would check it in. I'm happy with this wording. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1609847508 From angorya at openjdk.org Wed May 22 14:27:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 22 May 2024 14:27:17 GMT Subject: Integrated: 8313138: Scrollbar Keyboard enhancement In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 19:55:54 GMT, Andy Goryachev wrote: > Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal and vertical scrolling. The main reason for the change is to improve accessibility. > > **NOTE: For controls in right-to-left orientation, the direction of horizontal scrolling is reversed.** > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > public void verticalUnitScroll(boolean down); > > > Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. This pull request has now been integrated. Changeset: b685db23 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b685db23f07df32a3caea7af36206c48b52bb6eb Stats: 1283 lines in 15 files changed: 1221 ins; 37 del; 25 mod 8313138: Scrollbar Keyboard enhancement Reviewed-by: arapte, kcr, kizune ------------- PR: https://git.openjdk.org/jfx/pull/1393 From jvos at openjdk.org Wed May 22 15:11:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 22 May 2024 15:11:11 GMT Subject: RFR: 8332313: Update code review guidelines [v4] In-Reply-To: References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Overall, this is a great improvement. Reviewing code is a huge responsibility and it's good that we make it more clear now how we expect reviews to be executed. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2071576062 From fkirmaier at openjdk.org Wed May 22 15:50:46 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 22 May 2024 15:50:46 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v9] In-Reply-To: References: Message-ID: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/023613d6..adfc3ef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326 From kcr at openjdk.org Wed May 22 16:12:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 22 May 2024 16:12:12 GMT Subject: Integrated: 8332313: Update code review guidelines In-Reply-To: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> References: <4Fd0_WSKmOHwm_gPkUNN7ssX-jLFJ6wLUBppWgHhRTk=.aeacb2d9-8453-4066-82f4-d42c98fcda2e@github.com> Message-ID: On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) guidelines includes guidance for creating, reviewing, and integrating changes to JavaFX, along with a pointer to a [Code Review Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a goal of improving JavaFX and decreasing the chance of introducing a serious regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements This pull request has now been integrated. Changeset: 94aa2b68 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/94aa2b68d01af6096a18316ab36c911fe8cec572 Stats: 119 lines in 2 files changed: 110 ins; 0 del; 9 mod 8332313: Update code review guidelines Reviewed-by: jhendrikx, angorya, nlisker, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1455 From kevin.rushforth at oracle.com Wed May 22 18:49:23 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 May 2024 11:49:23 -0700 Subject: PLEASE READ: Updates Code Review Policies Message-ID: <4f7058cd-ff91-44e2-ba4e-d7a35afce785@oracle.com> To: All jfx contributors, particularly those with a Reviewer or Committer role in the OpenJFX project on OpenJDK [1] As some of you are already aware, we have modified the JavaFX Code Review policies, including additional requirements for Reviewers, PR authors, and sponsoring Committers. The updated policy can be found in the README-code-reviews.md [2] doc in the mainline jfx repo; it is linked from the CONTRIBUTING.md [3] doc. Everyone contributing, reviewing or sponsoring a PR should become familiar with the updated Code Review Policies. ACTION: All Reviewers should read the "Guidelines for reviewing a PR" [4] section of the Code Review Policies ACTION: All PR authors, sponsoring Committers, and Reviewers should read the "Before you integrate or sponsor a PR" section [5] of the Code Review Policies Let me know if you have any questions. -- Kevin [1] https://openjdk.org/census#openjfx [2] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md [3] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md [4] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md#guidelines-for-reviewing-a-pr [5] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md#before-you-integrate-or-sponsor-a-pr From tsayao at openjdk.org Wed May 22 21:32:16 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 22 May 2024 21:32:16 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage Message-ID: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> This fixes two bugs appointed on the JBS issue: 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. This seems to happen on newer versions of linux distros. 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). ------------- Commit messages: - Fix - Teste - Teste - Teste - Fix 8332222 Changes: https://git.openjdk.org/jfx/pull/1460/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332222 Stats: 45 lines in 3 files changed: 28 ins; 6 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1460.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1460/head:pull/1460 PR: https://git.openjdk.org/jfx/pull/1460 From tsayao at openjdk.org Wed May 22 21:42:09 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 22 May 2024 21:42:09 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v11] In-Reply-To: References: Message-ID: On Sun, 12 May 2024 11:03:36 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Use prismES2EGLX11 as build name Reopening so maybe it could be usefult to [8332108](https://bugs.openjdk.org/browse/JDK-8332108) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2125800352 From tsayao at openjdk.org Wed May 22 22:02:33 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 22 May 2024 22:02:33 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v12] In-Reply-To: References: Message-ID: > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'refs/heads/master' into egl - Use prismES2EGLX11 as build name - Merge branch 'master' into egl - Prefer EGL over GLX - Merge branch 'master' into egl - Merge branch 'master' into egl # Conflicts: # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c - Use EGL instead of GLX ------------- Changes: https://git.openjdk.org/jfx/pull/1381/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=11 Stats: 2441 lines in 36 files changed: 1857 ins; 489 del; 95 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381 From tsayao at openjdk.org Wed May 22 22:15:11 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 22 May 2024 22:15:11 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v12] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 22:02:33 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'refs/heads/master' into egl > - Use prismES2EGLX11 as build name > - Merge branch 'master' into egl > - Prefer EGL over GLX > - Merge branch 'master' into egl > - Merge branch 'master' into egl > > # Conflicts: > # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c > - Use EGL instead of GLX Testing [8332108](https://bugs.openjdk.org/browse/JDK-8332108) with this branch seems to have a significance in favor of EGL: Using this branch, compare the attached example with and without `-Dprism.es2.forceGLX=true` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2125863535 From kevin.rushforth at oracle.com Wed May 22 23:24:30 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 May 2024 16:24:30 -0700 Subject: CFV: New OpenJFX Reviewer: John Hendrikx Message-ID: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. John is an OpenJFX community member, who has contributed 39 commits [2] to OpenJFX. John regularly participates in code reviews, especially in the areas of JavaFX properties, scene graph and UI controls, offering valuable feedback. Votes are due by June 5, 2024 at 23:59 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#jhendrikx [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%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 Wed May 22 23:25:09 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 22 May 2024 16:25:09 -0700 Subject: CFV: New OpenJFX Reviewer: John Hendrikx In-Reply-To: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> References: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> Message-ID: Vote: YES -- Kevin On 5/22/2024 4:24 PM, Kevin Rushforth wrote: > I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. From andy.goryachev at oracle.com Wed May 22 23:51:12 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 22 May 2024 23:51:12 +0000 Subject: CFV: New OpenJFX Reviewer: John Hendrikx In-Reply-To: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> References: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> Message-ID: Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, May 22, 2024 at 16:24 To: openjfx-dev , John Hendrikx Subject: CFV: New OpenJFX Reviewer: John Hendrikx I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. John is an OpenJFX community member, who has contributed 39 commits [2] to OpenJFX. John regularly participates in code reviews, especially in the areas of JavaFX properties, scene graph and UI controls, offering valuable feedback. Votes are due by June 5, 2024 at 23:59 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#jhendrikx [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%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 duke at openjdk.org Thu May 23 03:37:11 2024 From: duke at openjdk.org (duke) Date: Thu, 23 May 2024 03:37:11 GMT Subject: Withdrawn: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1387 From kpk at openjdk.org Thu May 23 06:10:06 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 23 May 2024 06:10:06 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage In-Reply-To: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: On Wed, 22 May 2024 21:28:47 GMT, Thiago Milczarek Sayao wrote: > This fixes two bugs appointed on the JBS issue: > > 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. > > This seems to happen on newer versions of linux distros. > > 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). I was checking if this fix resolves the issue reported in [JDK-8332352](https://bugs.openjdk.org/browse/JDK-8332352) and found that this fix is causing change of behaviour in Ubuntu with KDE desktop environment. To reproduce the issue follow the steps given in [JDK-8332352](https://bugs.openjdk.org/browse/JDK-8332352). On selecting File menu, the popup window remains open until the mouse is pressed and closes as the mouse is released. The popup window is also not displayed below the File menu, it gets displayed with some offset, almost on the centre of the screen. This issue is not observed in MacOS. Screen recording of the above issue https://github.com/openjdk/jfx/assets/26969459/1a8cc7ce-5cd0-4562-85cb-01ea7f02b1de ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126302490 PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126305088 From tsayao at openjdk.org Thu May 23 10:29:33 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 23 May 2024 10:29:33 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v2] In-Reply-To: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> > This fixes two bugs appointed on the JBS issue: > > 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. > > This seems to happen on newer versions of linux distros. > > 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Should still report location ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1460/files - new: https://git.openjdk.org/jfx/pull/1460/files/b3c7f407..7f6221a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=00-01 Stats: 18 lines in 1 file changed: 5 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1460.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1460/head:pull/1460 PR: https://git.openjdk.org/jfx/pull/1460 From tsayao at openjdk.org Thu May 23 10:34:10 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 23 May 2024 10:34:10 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v2] In-Reply-To: <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> Message-ID: On Thu, 23 May 2024 10:29:33 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Should still report location I think the mouse behavior is expected, since there is a pointer grab on popups. But the location was wrong. It's fixed now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126771948 From tsayao at openjdk.org Thu May 23 10:40:07 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 23 May 2024 10:40:07 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v2] In-Reply-To: <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> Message-ID: <9R-MgIKD78WDxBYWwdcDzDBzbhDa2jd6RW5Y6yKEXYs=.f384b956-4eed-4926-a6cc-18847a58e2b0@github.com> On Thu, 23 May 2024 10:29:33 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Should still report location The linux build seems to be failing because the lack of gcc-13 package. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126782606 From tsayao at openjdk.org Thu May 23 10:53:36 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 23 May 2024 10:53:36 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> Message-ID: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> > This fixes two bugs appointed on the JBS issue: > > 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. > > This seems to happen on newer versions of linux distros. > > 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'refs/heads/master' into 8332222 - Should still report location - Fix - Teste - Teste - Teste - Fix 8332222 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1460/files - new: https://git.openjdk.org/jfx/pull/1460/files/7f6221a2..bb9a90b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=01-02 Stats: 55624 lines in 196 files changed: 29519 ins; 14601 del; 11504 mod Patch: https://git.openjdk.org/jfx/pull/1460.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1460/head:pull/1460 PR: https://git.openjdk.org/jfx/pull/1460 From jpereda at openjdk.org Thu May 23 10:53:36 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 23 May 2024 10:53:36 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v2] In-Reply-To: <9R-MgIKD78WDxBYWwdcDzDBzbhDa2jd6RW5Y6yKEXYs=.f384b956-4eed-4926-a6cc-18847a58e2b0@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> <9R-MgIKD78WDxBYWwdcDzDBzbhDa2jd6RW5Y6yKEXYs=.f384b956-4eed-4926-a6cc-18847a58e2b0@github.com> Message-ID: On Thu, 23 May 2024 10:37:09 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Should still report location > > The linux build seems to be failing because the lack of gcc-13 package. @tsayao the Ubuntu runner uses now 24.0.4. Your branch just needs to be synced with head. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126802774 From thiago.sayao at gmail.com Thu May 23 11:16:04 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 23 May 2024 08:16:04 -0300 Subject: Toolkit Window Decorations Message-ID: Hi, At some point we will need "Client Side" decorations on JavaFX to support modern gnome desktop on Linux as they moved to have client side decorations on everything. Mutter (the gnome compositor) does not even support "server side" decorations. On Wayland it's an extension for KDE only. Currently, even on Xorg it's a bit hacky when JavaFX needs to set total window size (with decorations). It caused too many problems. Having controls on the titlebar is a nice feature to have, as seen on many applications (tabs, hamburger menus, buttons). I'm not exactly sure on how it should be done. Maybe a Scene property that enables its contents to be wrapped in a decoration control? Would it break applications that walk through the scene graph? Should it look like Modena and have a JavaFX "identity", or should it try to look like the platform it's in? On Wayland, it would be possible to use a subcompositor to place the decoration behind, but I think it would be better if the decoration was part of the Scene. It would be less problematic on the variety of compositors (Mutter, Kwin, Sway, etc). -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Thu May 23 12:15:09 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 23 May 2024 12:15:09 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v2] In-Reply-To: References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <-bDjvHPoxU9h3QLcsTTKpraBROcX9Z5MMD1Ot7NODkQ=.fe9e7d45-23af-4f8e-b7be-2b1f91fe04a5@github.com> <9R-MgIKD78WDxBYWwdcDzDBzbhDa2jd6RW5Y6yKEXYs=.f384b956-4eed-4926-a6cc-18847a58e2b0@github.com> Message-ID: On Thu, 23 May 2024 10:48:08 GMT, Jose Pereda wrote: >> The linux build seems to be failing because the lack of gcc-13 package. > > @tsayao the Ubuntu runner uses now 24.0.4. Your branch just needs to be synced with head. @jperedadnr Thanks. @karthikpandelu I tested the sample with the Debian 12 VM and it seems to work now. Would you re-test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126955548 From mhanl at openjdk.org Thu May 23 12:45:09 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 12:45:09 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: <7LjY-L_C524gn6wWz8zJYWbzRQKZNz2SxKK8QFcLYN8=.f17c8e93-dc9b-4c76-878a-39bcdbc7768f@github.com> Message-ID: On Fri, 8 Mar 2024 16:39:56 GMT, Marius Hanl wrote: >> This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. >> >> Also, if this fixed [JDK-8316425](https://bugs.openjdk.org/browse/JDK-8316425), then that bug should be closed as a duplicate of this one. >> >> @lukostyra @arapte can you also review this? > >> This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. > > I thought about this as well but could not find any problem at least on Windows. > If we want to be perfectly safe, we may still want to set the flag when `sizeToScene()` is called. What do you think? > > I used the following code to test this, and it didn't matter when `sizeToScene()` was called: > > > @Override > public void start(Stage primaryStage) throws Exception { > StackPane root = new StackPane(); > Button wss = new Button("Wss"); > wss.setPrefSize(50, 50); > root.getChildren().add(wss); > > Scene scene = new Scene(root); > > Stage stage = new Stage(); > stage.setWidth(500); > stage.setMaximized(true); > stage.sizeToScene(); > stage.setScene(scene); > stage.show(); > } > @Maran23 I think this is pretty close to being ready to go in. At a minimum, you will need to merge master and then fix the test so that it will compile, and then create a CSR with the updated specification (I can help with that if needed). My only other suggestion was around additional tests that might be useful, but they could be done as a follow-on fix. Yes, sure, I've just been very busy with my day job over the last few weeks. I hopefully have more time now though :) And I totally agree with writing more tests, always good to have and to ensure quality. So no need for a follow-on ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2127013006 From mhanl at openjdk.org Thu May 23 12:48:22 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 12:48:22 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v8] In-Reply-To: References: Message-ID: <0VLk_vOfHcZGmJtT4MXSVBBIoJdP_zvdoDMQzBC6XUo=.9c57b55d-37ef-4f1c-b4eb-15deb7f3a9fc@github.com> > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ > See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [x] Adjust copyright > - [x] Write Systemtest > - [x] Document the new behaviour - in general, there should be more information what to expect Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? - Integrate changes as outline by beldenfox - test for multiple nested event loops - try leave outer loop after finishing inner loop - update copyright - trigger an outer nested event loop leave attempt - do not attempt to leave eventloop after leaving another eventloop - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop - ... and 1 more: https://git.openjdk.org/jfx/compare/ea0d1a15...ec43f2e3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/bba7fc23..ec43f2e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=06-07 Stats: 86781 lines in 1031 files changed: 46446 ins; 20952 del; 19383 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From mhanl at openjdk.org Thu May 23 12:56:22 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 12:56:22 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-snapping-x-y-tableview-scroll-3 # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java - JDK-8218745: TableView: visual glitch at borders on horizontal scrolling ------------- Changes: https://git.openjdk.org/jfx/pull/1330/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1330&range=01 Stats: 306 lines in 14 files changed: 122 ins; 41 del; 143 mod Patch: https://git.openjdk.org/jfx/pull/1330.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1330/head:pull/1330 PR: https://git.openjdk.org/jfx/pull/1330 From mhanl at openjdk.org Thu May 23 13:51:09 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 13:51:09 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v3] In-Reply-To: <16tHtx97hXBO0ouOygAIlrJvp12xtFkiuk4yWpTAfDw=.81eaabda-6c47-47f6-950b-464b35a61ee7@github.com> References: <16tHtx97hXBO0ouOygAIlrJvp12xtFkiuk4yWpTAfDw=.81eaabda-6c47-47f6-950b-464b35a61ee7@github.com> Message-ID: On Tue, 30 Apr 2024 23:20:59 GMT, Kevin Rushforth wrote: > * I wanted to verify different orders of operation, so I wrote a (manual) test program I'm retesting and writing tests right now and reproduced one usecase out of my head that indeed 'fails' now. Take the following code: Button button = new Button(); button.setMinSize(440, 440); Scene scene = new Scene(button); stage.setTitle("JavaFX test stage!"); stage.setScene(scene); stage.setWidth(50); stage.setHeight(50); stage.setFullScreen(true); stage.sizeToScene(); stage.setFullScreen(false); stage.show(); With my logic, the `sizeToScene()` flag is not remembered, so the scene is not adjusted in the `sizeToScene` style after I 'go out' of fullscreen mode. If I do instead: stage.sizeToScene(); stage.setFullScreen(true); stage.setFullScreen(false); The flag is remembered and the scene has the size of the button. Not sure what the expectation is here, but we could fix this problem by still remembering the flag if called. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2127160594 From mhanl at openjdk.org Thu May 23 14:01:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 14:01:40 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v4] In-Reply-To: References: Message-ID: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Implement isSizeToSceneAllowed() method to determines whether the sizeToScene() request is allowed. Implement much more tests - Merge branch 'master' of https://github.com/openjdk/jfx into jdk-8326619-maximize-minimize-scene - improve tests - JDK-8326619: Improve tests - JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1382/files - new: https://git.openjdk.org/jfx/pull/1382/files/e58a2fda..eeab0fa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=02-03 Stats: 88862 lines in 1197 files changed: 47740 ins; 21303 del; 19819 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From eduard.sdv at web.de Thu May 23 14:16:45 2024 From: eduard.sdv at web.de (Eduard Sedov) Date: Thu, 23 May 2024 16:16:45 +0200 Subject: prism.maxvram limitation In-Reply-To: References: Message-ID: <525bef91-8143-4724-b675-1c780f1cffd3@web.de> Hi all, Any ideas or suggestions? Thanks. Eduard Am 14. Mai 2024, 15:45, um 15:45, Eduard Sedov schrieb: >Hi all, > >There is a long-lived bug in JavaFX: JDK-8089112: Need to handle the >case of a failed texture load when rendering large images > >JavaFX manages a pool of resources that is limited to 512Mbytes by >default. This limit can be increased by setting the 'prism.maxvram' >system property. > >This limit is reasonable for the GraphicsPipelines (the D3DPipeline and >the ES2Pipeline) that are backed by a graphics device that has such a >limitation. > >But it does not make sense for pipelines that use only the main memory: >the J2DPipeline and perhaps the SWPipeline. > >The J2DPipeline is currently used for printing. For example, printing >an image on Letter paper using 600PPI printer requires 134_640_000 >bytes. When the printed image is redirected to a PDF printer, even >higher resolution is needed to get adequate quality because the PDF can >zoom in. This often exceeds the limitation and ends in a >NullPointerException if the allocated textures exceed the specified >maxvram value. > >There is no way to specify different values for each pipeline or to >remove the limitation for software pipelines. > >I would add this possibility? What do you think? > >Thanks, >Eduard > >?? From mhanl at openjdk.org Thu May 23 14:24:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 14:24:08 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: <5e4e8YYMWDZJkUt-YkNG4S_cPLyWMfcvBcsKc3e6pj4=.52959ca8-4b40-4ba8-886e-29689f5a265c@github.com> References: <5e4e8YYMWDZJkUt-YkNG4S_cPLyWMfcvBcsKc3e6pj4=.52959ca8-4b40-4ba8-886e-29689f5a265c@github.com> Message-ID: On Tue, 14 May 2024 18:42:47 GMT, Martin Fox wrote: > On Linux leaveNestedEventLoop makes changes in glass that cannot be erased or undone (it calls gtk_main_quit which updates internal GTK state that we don?t have access to). In the end GTK will exit the loops in the correct order but it will exit loop A before the core code has a chance to call Application.leaveNestedEventLoop again. This is throwing off the bookkeeping including some debug checks. That is exactly what I also figured out. If a second new nested event loop is started directly after the first one was requested to leave, the native code will never 'return'. That's why this code exists: https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/EventLoop.java#L118 which I slightly modified to not run `invokeLater` in my PR. Otherwise it would never return any value and code after `enterNestedEventLoop` is never called: Object o = Platform.enterNestedEventLoop(this); System.out.println(o); // <- never called And since you fixed the event jam so that we are not stuck anymore and Linux is implemented different with a global stateful variable, we will get that 'inconsistency', which I don't think is relevant or a problem here, hence I removed it in my PR. I also don't found any other way to deal with that situation, as you also stated, there is nothing else we can do, and while the other OS implementation have some kind of while loop where we can try to implement something, on the Linux side we completely rely on `gtk_main` and `gtk_main_quit`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2127252021 From mhanl at openjdk.org Thu May 23 14:54:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 14:54:36 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v4] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css - Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay - JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/093b36f6..5af893c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=02-03 Stats: 88104 lines in 1155 files changed: 47257 ins; 21123 del; 19724 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Thu May 23 14:56:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 14:56:26 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v9] In-Reply-To: References: Message-ID: <3d5z87Jiual0yPmO_3lC_2_XIdC8B3szrR5Lbf3WUrY=.22507214-1420-4320-b9df-0d67ae3fef10@github.com> > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ > See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [x] Adjust copyright > - [x] Write Systemtest > - [x] Document the new behaviour - in general, there should be more information what to expect Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Fix javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/ec43f2e3..ede84ef1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From kcr at openjdk.org Thu May 23 15:28:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 15:28:28 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX Message-ID: [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. ------------- Commit messages: - Replace all occurrences of '///' Changes: https://git.openjdk.org/jfx/pull/1461/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332732 Stats: 1309 lines in 50 files changed: 0 ins; 0 del; 1309 mod Patch: https://git.openjdk.org/jfx/pull/1461.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1461/head:pull/1461 PR: https://git.openjdk.org/jfx/pull/1461 From kcr at openjdk.org Thu May 23 15:28:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 15:28:28 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 15:22:38 GMT, Kevin Rushforth wrote: > [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). > > This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: > > 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` > 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. > > This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). > > As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java line 352: > 350: // Only one '/' after the ':'. > 351: if (protocol.equals("file")) { > 352: // Map "file:/somepath" to "file:///somepath" I did this one by hand, adding the `"` chars so that the automated program wouldn't touch the `///` in `file:///`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1461#discussion_r1611906488 From angorya at openjdk.org Thu May 23 15:44:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 15:44:07 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 15:22:38 GMT, Kevin Rushforth wrote: > [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). > > This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: > > 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` > 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. > > This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). > > As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. went through all 50 files, all is good. ship it! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1461#pullrequestreview-2074364579 From mstrauss at openjdk.org Thu May 23 16:04:10 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 23 May 2024 16:04:10 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 19:22:39 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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: > > - Merge branch 'master' into 8319555.manual > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - ... and 5 more: https://git.openjdk.org/jfx/compare/681030f4...e4c8d29a I run manual tests on the command line like so: java --module-path=$env:JFX_SDK --add-modules=javafx.controls ./tests/manual/events/PlatformPreferencesChangedTest.java This doesn't work with the new utility class, since it is outside of the class file hierarchy. Short of using a build system, how would I run a manual test with this new class? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127511624 From angorya at openjdk.org Thu May 23 16:17:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 16:17:07 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 16:01:29 GMT, Michael Strau? wrote: > Short of using a build system, how would I run a manual test with this new class? I am running from within Eclipse. Here is the command line (remove newlines) it launches the EmojiTest. I think the key is to add the location of compiled classes via `-classpath`: /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/java -XX:+ShowCodeDetailsInExceptionMessages -Dfile.encoding=UTF-8 -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8 -p /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.base/bin:/Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/bin:/Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.controls/bin -classpath /Users/angorya/Projects/jfx-1/jfx/rt/tests/manual/util/bin:/Users/angorya/Projects/jfx-1/jfx/rt/tests/manual/text/bin --add-reads javafx.base=java.management --add-reads javafx.base=jdk.management --add-exports javafx.base/com.sun.javafx.property=javafx.graphics --add-exports javafx.base/test.javafx.collections=javafx.graphics --add-exports javafx.base/test.util.memory=javafx.graphics --add-exports java.base/sun.security.util=javafx.graphics --add-reads javafx.base=java.management --add-reads javafx.base=jdk.management --add-exports javafx.graphics/test.com.sun.javafx.pgstub=javafx.controls --add-exports javafx.base/test.com.sun.javafx.binding=javafx.controls --add-exports javafx.base/test.util.memory=javafx.controls --add-exports javafx.base/test.javafx.collections=javafx.controls --add-exports javafx.base/com.sun.javafx.property=javafx.graphics --add-exports javafx.base/test.javafx.collections=javafx.graphics --add-exports javafx.base/test.util.memory=javafx.graphics --add-exports java.base/sun.security.util=javafx.graphics --add-reads javafx.base=java.management --add-reads javafx.base=jdk.management --add-modules=javafx.base,javafx.graphics,javafx.controls --add-opens javafx.controls/test.com.sun.javafx.scene.control.test=javafx.base --add-exports javafx.base/com.sun.javafx=ALL-UNNAMED -Djava.library.path=../../../build/sdk/lib EmojiTest (also, there might be some unnecessary -add-exports here as well) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127537453 From angorya at openjdk.org Thu May 23 16:17:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 16:17:09 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 19:22:39 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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: > > - Merge branch 'master' into 8319555.manual > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - ... and 5 more: https://git.openjdk.org/jfx/compare/f8384dd1...e4c8d29a But this is a good question: is there a better way to organize the tests to make it easier to use common code? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127540895 From michaelstrau2 at gmail.com Thu May 23 16:19:58 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 23 May 2024 18:19:58 +0200 Subject: prism.maxvram limitation In-Reply-To: References: Message-ID: I wonder why there's a software-defined limit in the first place, given that there doesn't seem to be a way for JavaFX to gracefully handle failed texture loads. You say that the limit is reasonable for GPUs, but why is this any different from system memory? GPUs come in all different kinds of sizes, why is 512 MB any more significant than 256 MB or 8 GB? It's an arbitrary value that might be too small for some systems, and too large for other systems. Right now, JavaFX simply bugs out when the limit is reached. Unless a graceful degradation capability is added, I suggest to remove the limit entirely and let JavaFX bug out when the actual hardware limits are reached. On Tue, May 14, 2024 at 4:14?PM Eduard Sedov wrote: > > Hi all, > > There is a long-lived bug in JavaFX: JDK-8089112: Need to handle the case of a failed texture load when rendering large images > > JavaFX manages a pool of resources that is limited to 512Mbytes by default. This limit can be increased by setting the 'prism.maxvram' system property. > > This limit is reasonable for the GraphicsPipelines (the D3DPipeline and the ES2Pipeline) that are backed by a graphics device that has such a limitation. > > But it does not make sense for pipelines that use only the main memory: the J2DPipeline and perhaps the SWPipeline. > > The J2DPipeline is currently used for printing. For example, printing an image on Letter paper using 600PPI printer requires 134_640_000 bytes. When the printed image is redirected to a PDF printer, even higher resolution is needed to get adequate quality because the PDF can zoom in. This often exceeds the limitation and ends in a NullPointerException if the allocated textures exceed the specified maxvram value. > > There is no way to specify different values for each pipeline or to remove the limitation for software pipelines. > > I would add this possibility? What do you think? > > Thanks, > Eduard > > ? From angorya at openjdk.org Thu May 23 16:25:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 16:25:10 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 15:22:38 GMT, Kevin Rushforth wrote: > [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). > > This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: > > 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` > 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. > > This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). > > As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. Are these all the places where javadoc fails, or more files are coming separately? For example, see AccordionBehavior:151, ChoiceBoxSkin:327 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1461#issuecomment-2127565321 From mstrauss at openjdk.org Thu May 23 16:28:07 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 23 May 2024 16:28:07 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 16:11:42 GMT, Andy Goryachev wrote: > > Short of using a build system, how would I run a manual test with this new class? > > I am running from within Eclipse. Here is the command line (remove newlines) it launches the EmojiTest. I think the key is to add the location of compiled classes via `-classpath`: Yes this will work, but it requires me to compile `ManualTestWindow.java` before. That's quite a lot of heavy-lifting without tooling support (like you get from Eclipse). Maybe we should integrate the manual tests into the Gradle build, so that running a manual test might be as easy as invoking the application plugin's `:run` task for the manual test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127576658 From kcr at openjdk.org Thu May 23 17:41:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 17:41:10 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: <3Pp7cptwqat_WUhM2yMuA0mmsvMzJj_XsNeQqmafA5w=.d8c603dc-26fd-41d1-8f53-1b4520f1f394@github.com> On Fri, 17 May 2024 19:22:39 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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: > > - Merge branch 'master' into 8319555.manual > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - ... and 5 more: https://git.openjdk.org/jfx/compare/1c6a743c...e4c8d29a We need to provide a build script for any manual test that isn't self-contained in a single directory (see my earlier comment). For example, we have a build script for MonkeyTester and FXMediaPlayer. As a separate step, we could make it available as part of the gradle build, as long as we can do it without adding individual tests to build.gradle (sort of like we do for apps), but the previous is the minimum. This should probably be put on the back burner until the next test sprint. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127713126 From angorya at openjdk.org Thu May 23 17:49:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 17:49:10 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: <8_RtUtk60A6dPKYbWJ1BjlCdt-EGQD3z7VWS9YmAzwE=.38a02f9a-77b1-4bc2-ad33-5430d07a17df@github.com> On Fri, 17 May 2024 19:22:39 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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: > > - Merge branch 'master' into 8319555.manual > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - ... and 5 more: https://git.openjdk.org/jfx/compare/399917f0...e4c8d29a or possibly build the common test code into a jar as a part of the standard build and include it along with `-Djava.library.path`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2127727571 From kcr at openjdk.org Thu May 23 17:51:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 17:51:07 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 16:21:06 GMT, Andy Goryachev wrote: > Are these all the places where javadoc fails, or more files are coming separately? There are only 5 places where javadoc fails with the latest JDK 23. By eliminating all cases where we have more than three slashes, this PR fixes those 5 as well as avoids a pattern that could cause problems in the future. > For example, see AccordionBehavior:151, ChoiceBoxSkin:327 Not sure what you mean here. Those lines are modified by this PR such that they no longer have more than 2 slashes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1461#issuecomment-2127729783 From angorya at openjdk.org Thu May 23 17:59:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 17:59:07 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: <3Co3-I2wjJTylzCILT6vaktkdIDSrDv53Coull53e-Y=.e0767224-48a9-45b6-a901-64c6435cae1a@github.com> On Thu, 23 May 2024 17:48:15 GMT, Kevin Rushforth wrote: > Those lines are modified by this PR You are right! I had cached java files in build/modulal-sdk/modules_src which Eclipse search picked up. Apparently, there is a way to mark the folder as "derived" so it will be ignored by the Search, but that hits an 18-year old Eclipse bug... https://bugs.eclipse.org/bugs/show_bug.cgi?id=154089 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1461#issuecomment-2127741418 From kcr at openjdk.org Thu May 23 18:06:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 18:06:08 GMT Subject: RFR: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 15:22:38 GMT, Kevin Rushforth wrote: > [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). > > This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: > > 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` > 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. > > This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). > > As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. Thanks for checking. After this PR there should be no instances of `///` outside of String literals any `.java` file in the repo. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1461#issuecomment-2127752977 From angorya at openjdk.org Thu May 23 21:08:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 21:08:08 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests [v9] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 19:22:39 GMT, Andy Goryachev wrote: >> ## ManualTestWindow >> >> This facility provides the base class for manual tests which displays the test instructions, >> the UI under test, and the Pass/Fail buttons. >> >> Example: >> >> >> public class ManualTestExample extends ManualTestWindow { >> public ManualTestExample() { >> super( >> "Manual Test Example", >> """ >> Instructions: >> 1. you will see a button named "Test" >> 2. press the button >> 3. verify that the button can be pressed""", >> 400, 250 >> ); >> } >> >> public static void main(String[] args) throws Exception { >> launch(args); >> } >> >> @Override >> protected Node createContent() { >> return new Button("Test"); >> } >> } >> >> >> Resulting application window: >> >> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724) >> >> Readme: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md >> >> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now). >> >> Q: What other features can be added to the test window? >> >> Edit: the sources are left in their original place at the root of the project. > > 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: > > - Merge branch 'master' into 8319555.manual > - Merge remote-tracking branch 'origin/master' into 8319555.manual > - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual > - removed example > - cleanup > - whitespace > - extends application > - works > - . > - sources moved back > - ... and 5 more: https://git.openjdk.org/jfx/compare/c6b9c67e...e4c8d29a moving to DRAFT until the next test sprint (after jfx23 ships). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2128018657 From angorya at openjdk.org Thu May 23 21:24:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 21:24:09 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v4] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 14:54:36 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay > - JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Strange: I still see the same issue described in https://github.com/openjdk/jfx/pull/1394#issuecomment-1986520680 (the very first tooltip after updating stylesheet uses the old value) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2128039109 From mhanl at openjdk.org Thu May 23 21:56:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 21:56:14 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling Message-ID: Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. So the following code is effectively doing the same: Old: BaseBounds newClip = clipNode.getShape().getBounds(); if (!clipNode.getTransform().isIdentity()) { newClip = clipNode.getTransform().transform(newClip, newClip); } final BaseTransform curXform = g.getTransformNoClone(); final Rectangle curClip = g.getClipRectNoClone(); newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); Rectangle clipRect = new Rectangle(newClip) New: BaseTransform curXform = g.getTransformNoClone(); BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); Rectangle clipRect = new Rectangle(clipBounds); clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. I checked several scenarios and code and could not find any regressions. Still, since this is change affects all nodes with rectangular clips, we should be careful. Performance wise I could not spot any difference, I do not expect any difference. **So I would like to have at least 2 reviewers.** Note that I will do more testing as well soon on all JavaFX applications I have access to. --- As written in the other PR, I have some interesting findings on this particular problem. Copy&Paste from the other PR: -- Ok, so I found out the following: When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. This happens at the low level (`NGNode`) side of JavaFX. ... I could track it down to be a typical floating point problem ... The bug always appears when I scroll and the clip RectBounds are something like: `RectBounds { minX:6.999996, minY:37.0, maxX:289.00003, maxY:194.0} (w:282.00003, h:157.0)` ... while this does not happen when the value is something like: `RectBounds { minX:7.000004, minY:37.0, maxX:289.0, maxY:194.0} (w:282.0, h:157.0` Even more details: --- - As briefly explained above, due to floating point arithmetic, we may do not get the correct value, leading to an incorrect calculation where 1 pixel is missing. That is why this issue happens only on display scales other than integer values. - And since only the `ClippedContainer` changes its `layoutX` AND the `layoutX` of its clip, the bug only appears there - JavaFX Nodes uses `double`, while the low level side (NG) uses `float` mostly, which seems to make things less accurate, although not 100% sure if doubles will avoid this particular problem completely, probably not. I'm not sure why this decision was made. ------------- Commit messages: - 8218745: TableView: visual glitch at borders on horizontal scrolling Changes: https://git.openjdk.org/jfx/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8218745 Stats: 255 lines in 11 files changed: 173 ins; 58 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/1462.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1462/head:pull/1462 PR: https://git.openjdk.org/jfx/pull/1462 From kcr at openjdk.org Thu May 23 22:05:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 22:05:05 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... I'm reasonably sure there was a good reason for the code in NGNode doing what it did. This will need very careful review and testing before we would accept it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2128092151 From mhanl at openjdk.org Thu May 23 22:17:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 22:17:36 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v5] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Add more documentation and improve css stylesheet test threshold ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/5af893c1..a3f9f609 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=03-04 Stats: 18 lines in 4 files changed: 8 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Thu May 23 22:17:38 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 22:17:38 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v4] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 14:54:36 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay > - JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed > Strange: I still see the same issue described in [#1394 (comment)](https://github.com/openjdk/jfx/pull/1394#issuecomment-1986520680) (the very first tooltip after updating stylesheet uses the old value) I don't know what is happening there, are you sure that there isn't a problem on your side? Testing `Tooltip` with a normal stylesheet added to the scene works perfectly fine for me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2128120302 From kcr at openjdk.org Thu May 23 22:23:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 22:23:05 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... Reviewers: @arapte @andy-goryachev-oracle @Maran23 wait for either @arapte or me to review the proposed Prism changes in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2128133133 From angorya at openjdk.org Thu May 23 22:26:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 22:26:06 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v5] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 22:17:36 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Add more documentation and improve css stylesheet test threshold I am not sure what the difference might be. The code in the MonkeyTester generates a stylesheet, encodes it in base64 data url and adds it to all scenes in the application (it also removes the old version, if any). The stylesheet gets loaded - I can see it by slightly changed colors and the fact that the tooltip show delay gets changed on the second and any subsequent invocations. Can you try it? https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2128136276 From angorya at openjdk.org Thu May 23 22:33:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 23 May 2024 22:33:12 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v5] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 22:17:36 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Add more documentation and improve css stylesheet test threshold with the latest monkey tester I see that updating the stylesheet does not update the showingDelay property immediately. When the tooltip gets shown, I see the following output from the change listener added to this property: showDelay=1000.0 ms showDelay=100.0 ms I suppose the second setting of 100ms (the value I actually set) happens too late or simply is ignored. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2128142633 From mhanl at openjdk.org Thu May 23 22:42:05 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 22:42:05 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 22:02:41 GMT, Kevin Rushforth wrote: > I'm reasonably sure there was a good reason for the code in NGNode doing what it did. This will need very careful review and testing before we would accept it. 100% agree. Note that the code there is a shortcut for performance reasons. Removing it will also fix the bug since the code below is doing the right thing, but will probably result in a performance impact. Thats why I checked the other path and had a closer look what it does, since it still needs to the right for whatever clip is used. And there I saw that is does nearly the same thing, but with the `getClippedBounds` instead. With that in mind, we need to especially check if the fast path did something completely unexpected what the other 'slow' path did not and we may miss now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2128150585 From mhanl at openjdk.org Thu May 23 22:47:10 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 22:47:10 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 99: > 97: /* > 98: * Copied from removed StyleClassSet to give StyleClasses a fixed index when > 99: * first encountered. No longer needed once StyleClass is removed. Is this a possible idea for the future? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1612425514 From mhanl at openjdk.org Thu May 23 22:57:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 23 May 2024 22:57:14 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff Code looks good to me. As mentioned above, I tested it already and everything was good, so I'm certain that there is no regression here. I'm generally not a big fan of 'reimplementing' Collections, but I can see why it is needed here and it also makes sense, especially for something like CSS which needs to be fast. Something I saw as well in Swing (just check the `ArrayTable` class ? ). I wonder if we may want to add some tests for the `FixedCapacitySet`? ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2075265208 From kcr at openjdk.org Thu May 23 23:07:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 23 May 2024 23:07:12 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff I'm in the process of testing this. I'll do that and report back. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2128170412 From kcr at openjdk.org Fri May 24 00:14:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 00:14:08 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff Code looks good. Testing looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2075329950 From jdv at openjdk.org Fri May 24 06:53:27 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 24 May 2024 06:53:27 GMT Subject: RFR: 8332863: Crash in JPEG decoder if we enable MEM_STATS Message-ID: In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is not defined and we don't see any issue) to enable printing of memory statistics log. But if we enable it, we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000001269d5164, pid=47784, tid=259 # # JRE version: Java(TM) SE Runtime Environment (21.0+35) (build 21+35-LTS-2513) # Java VM: Java HotSpot(TM) 64-Bit Server VM (21+35-LTS-2513, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # C [libjavafx_iio.dylib+0x49164] free_pool+0x88 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. --------------- T H R E A D --------------- Current thread (0x0000000121a42c00): JavaThread "JavaFX Application Thread" [_thread_in_native, id=259, stack(0x000000016d11c000,0x000000016d918000) (8176K)] Stack: [0x000000016d11c000,0x000000016d918000], sp=0x000000016d912780, free space=8153k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libjavafx_iio.dylib+0x49164] free_pool+0x88 C [libjavafx_iio.dylib+0x49410] self_destruct+0x3c C [libjavafx_iio.dylib+0xe888] jpeg_destroy+0x3c C [libjavafx_iio.dylib+0x4bb1c] imageio_dispose+0x98 C [libjavafx_iio.dylib+0x4b178] disposeIIO+0x2c C [libjavafx_iio.dylib+0x4b140] Java_com_sun_javafx_iio_jpeg_JPEGImageLoader_disposeNative+0x2c This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in jpegloader.c->imageio_dispose() function. I have moved deletion of error handler logic after we destroy IJG stored objects in jpegloader.c->imageio_dispose(). This resolves this issue. There is no regression test case because we need to enable MEM_STATS flag to see this issue. Ran graphics unit tests also and i don't see any issues with this change. ------------- Commit messages: - 8332863: Crash in JPEG decoder if we enable MEM_STATS Changes: https://git.openjdk.org/jfx/pull/1463/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332863 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1463.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1463/head:pull/1463 PR: https://git.openjdk.org/jfx/pull/1463 From jhendrikx at openjdk.org Fri May 24 08:07:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 24 May 2024 08:07:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <8kLKufvDTHhGbysY8fgL5GlsKq7xpzhJUduBIj1UqFY=.246ce608-e208-46b3-8dba-0069fd5a0e9c@github.com> On Thu, 23 May 2024 22:44:08 GMT, Marius Hanl wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move getStyleClassNames to location it was introduced to reduce diff > > modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 99: > >> 97: /* >> 98: * Copied from removed StyleClassSet to give StyleClasses a fixed index when >> 99: * first encountered. No longer needed once StyleClass is removed. > > Is this a possible idea for the future? Yes, once this class is moved to private API (see https://github.com/openjdk/jfx/pull/1333) then this method can be removed. The `SimpleSelector` class is already deprecated for removal since 23. The method is almost impossible to reach (you'd have to cast to `SimpleSelector`), but removing it as part of this PR would have required a CSR making this harder to integrate. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1613039200 From jhendrikx at openjdk.org Fri May 24 08:26:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 24 May 2024 08:26:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Thu, 23 May 2024 22:54:15 GMT, Marius Hanl wrote: > Code looks good to me. As mentioned above, I tested it already and everything was good, so I'm certain that there is no regression here. > > I'm generally not a big fan of 'reimplementing' Collections, but I can see why it is needed here and it also makes sense, especially for something like CSS which needs to be fast. Something I saw as well in Swing (just check the `ArrayTable` class ? ). I'm not a fan either, especially because custom collection implementations when referred to by their interface may sneak their way through the various classes and eventually be returned to users. Any deviation from the collection contracts then suddenly is a bug users may encounter. I would have done this with plain `HashSet` (or `Set.of`) were it not for the fact that a lot of performance gains were possible due to the limited way FX is using these sets. > I wonder if we may want to add some tests for the `FixedCapacitySet`? Yeah, now that it is more likely that this will make it into FX, I will add a small set of unit tests for this class. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2128894297 From kpk at openjdk.org Fri May 24 09:42:08 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 24 May 2024 09:42:08 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 I can confirm that this now fixes the issue in Ubuntu with KDE desktop environment. Both [JDK-8332222](https://bugs.openjdk.org/browse/JDK-8332222) and [JDK-8332352](https://bugs.openjdk.org/browse/JDK-8332352) are reporting the same issue. So I will close the latter as duplicate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2129085714 From duke at openjdk.org Fri May 24 10:18:12 2024 From: duke at openjdk.org (drmarmac) Date: Fri, 24 May 2024 10:18:12 GMT Subject: RFR: 8311895: CSS Transitions [v16] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 08:40:28 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Future enhancements >> CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. >> >> In a follow-up PR, the following types will implement the `Interpolatable` interface: >> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: > > - Merge branch 'master' into feature/css-transitions > - update 'since' tags > - Fix javadoc error > - Change javadoc comment > - Merge branch 'master' into feature/css-transitions > - Discard redundant transitions in StyleableProperty impls > - Changes per review > - Merge branch 'master' into feature/css-transitions > - Merge branch 'master' into feature/css-transitions > - Add TransitionMediator > - ... and 43 more: https://git.openjdk.org/jfx/compare/aa9907a5...6614abb9 I did some testing of this PR and started looking into the implementation (see code comments). - Fade in / fade out with delay and various easing functions via the opacity property works as expected, , scaleX/scaleY also look good - Attempting to do background-color transitions doesn't work, I presume because it's not yet `Interpolatable` in this PR. Do we need to emit a warning in such a case? Right now the `transition` CSS code just seems to be ignored. - Same with the current limitation of not being able to mix shorthand and longhand notations, do we need a warning if it is attempted? - Generally this looks like a high quality PR, filling a long-standing gap. Currently available alternative solutions (e.g. using code-driven animations) are quite cumbersome and not easy to get right. modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 291: > 289: * All rise points are within the open interval (0..1). > 290: */ > 291: BOTH, Looks like the docs for BOTH and NONE are swapped? (this would also affect the CSR) modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9081: > 9079: TransitionDefinition transition = get(i); > 9080: > 9081: boolean selected = "all".equals(transition.propertyName()) Is "all" the same as `TransitionDefinitionCssMetaData.PROPERTY_ALL`, so the magic string can be avoided? modules/javafx.graphics/src/test/java/test/javafx/scene/Node_transition_Test.java line 162: > 160: List transitions = NodeShim.getTransitionDefinitions(node); > 161: assertEquals(3, transitions.size()); > 162: assertTransitionEquals("-fx-background-color", Duration.seconds(1), Duration.seconds(0.5), CSS_EASE, transitions.get(0)); `node` is a `Rectangle`, which doesn't have a `background`property. Doesn't hurt this specific test, but maybe it's better to use an existing property. ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2076453636 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613220507 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613227193 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613233729 From mstrauss at openjdk.org Fri May 24 11:18:35 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 24 May 2024 11:18:35 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Future enhancements > CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. > > In a follow-up PR, the following types will implement the `Interpolatable` interface: > `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'refs/heads/master' into feature/css-transitions - extract magic string to named constant - use existing property in test - fixed documentation - Merge branch 'master' into feature/css-transitions - update 'since' tags - Fix javadoc error - Change javadoc comment - Merge branch 'master' into feature/css-transitions - Discard redundant transitions in StyleableProperty impls - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 ------------- Changes: https://git.openjdk.org/jfx/pull/870/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=16 Stats: 4677 lines in 43 files changed: 4634 ins; 4 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Fri May 24 11:18:36 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 24 May 2024 11:18:36 GMT Subject: RFR: 8311895: CSS Transitions [v16] In-Reply-To: References: Message-ID: <10w2owNrK4xYD_zzTlcW7111x9zlNiHFXgVwCLhIhmg=.7b28dfb1-29a9-4a17-ad31-4b9b90627357@github.com> On Fri, 24 May 2024 10:02:44 GMT, drmarmac 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 53 commits: >> >> - Merge branch 'master' into feature/css-transitions >> - update 'since' tags >> - Fix javadoc error >> - Change javadoc comment >> - Merge branch 'master' into feature/css-transitions >> - Discard redundant transitions in StyleableProperty impls >> - Changes per review >> - Merge branch 'master' into feature/css-transitions >> - Merge branch 'master' into feature/css-transitions >> - Add TransitionMediator >> - ... and 43 more: https://git.openjdk.org/jfx/compare/aa9907a5...6614abb9 > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 291: > >> 289: * All rise points are within the open interval (0..1). >> 290: */ >> 291: BOTH, > > Looks like the docs for BOTH and NONE are swapped? (this would also affect the CSR) Good catch! I've also updated the CSR. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9081: > >> 9079: TransitionDefinition transition = get(i); >> 9080: >> 9081: boolean selected = "all".equals(transition.propertyName()) > > Is "all" the same as `TransitionDefinitionCssMetaData.PROPERTY_ALL`, so the magic string can be avoided? I've replaced `"all"` with a named constant in all relevant places. > modules/javafx.graphics/src/test/java/test/javafx/scene/Node_transition_Test.java line 162: > >> 160: List transitions = NodeShim.getTransitionDefinitions(node); >> 161: assertEquals(3, transitions.size()); >> 162: assertTransitionEquals("-fx-background-color", Duration.seconds(1), Duration.seconds(0.5), CSS_EASE, transitions.get(0)); > > `node` is a `Rectangle`, which doesn't have a `background`property. Doesn't hurt this specific test, but maybe it's better to use an existing property. I've changed the test to use `-fx-fill` instead. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613307416 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613307906 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1613308024 From mstrauss at openjdk.org Fri May 24 11:43:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 24 May 2024 11:43:14 GMT Subject: RFR: 8311895: CSS Transitions [v16] In-Reply-To: References: Message-ID: On Fri, 24 May 2024 10:15:37 GMT, drmarmac wrote: > * Attempting to do background-color transitions doesn't work, I presume because it's not yet `Interpolatable` in this PR. Do we need to emit a warning in such a case? Right now the `transition` CSS code just seems to be ignored. CSS transitions work with styleable properties that are either primitives or `Interpolatable` objects. So if you apply a transition to the sub-property `-fx-background-color`, what really happens is that the CSS subsystem creates a new `Background` instance and applies it to the `Region.background` property. However, since `Background` is not interpolatable, you won't see an animation. This will start to work once all relevant classes are interpolatable, which will come with a subsequent PR. I'm not sure if we really need a warning. The unexpected non-animation is really only due to a few missing interpolatable classes, which will be fixed soon. > * Same with the current limitation of not being able to mix shorthand and longhand notations, do we need a warning if it is attempted? This is out of scope for this PR, since the problem is not unique to the CSS `transition` property. We should improve the CSS parser to handle shorthand/longhand notations uniformly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2129318991 From kcr at openjdk.org Fri May 24 12:15:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 12:15:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Fri, 24 May 2024 08:22:28 GMT, John Hendrikx wrote: > > I wonder if we may want to add some tests for the `FixedCapacitySet`? > > Yeah, now that it is more likely that this will make it into FX, I will add a small set of unit tests for this class. Since this PR is ready to integrate, I think it would be fine to file a new test bug for the additional tests if you like. If you prefer to add the new tests now, that's fine, too (we can re-review it). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2129385052 From kcr at openjdk.org Fri May 24 12:22:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 12:22:08 GMT Subject: RFR: 8332863: Crash in JPEG decoder if we enable MEM_STATS In-Reply-To: References: Message-ID: On Fri, 24 May 2024 06:48:50 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is not defined and we don't see any issue) to enable printing of memory statistics log. But if we enable it, we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00000001269d5164, pid=47784, tid=259 > # > # JRE version: Java(TM) SE Runtime Environment (21.0+35) (build 21+35-LTS-2513) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (21+35-LTS-2513, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > --------------- T H R E A D --------------- > > Current thread (0x0000000121a42c00): JavaThread "JavaFX Application Thread" [_thread_in_native, id=259, stack(0x000000016d11c000,0x000000016d918000) (8176K)] > > Stack: [0x000000016d11c000,0x000000016d918000], sp=0x000000016d912780, free space=8153k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > C [libjavafx_iio.dylib+0x49410] self_destruct+0x3c > C [libjavafx_iio.dylib+0xe888] jpeg_destroy+0x3c > C [libjavafx_iio.dylib+0x4bb1c] imageio_dispose+0x98 > C [libjavafx_iio.dylib+0x4b178] disposeIIO+0x2c > C [libjavafx_iio.dylib+0x4b140] Java_com_sun_javafx_iio_jpeg_JPEGImageLoader_disposeNative+0x2c > > > This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in jpegloader.c->imageio_dispose() function. > > I have moved deletion of error handler logic after we destroy IJG stored objects in jpegloader.c->imageio_dispose(). This resolves this issue. > There is no regression test case because we need to enable MEM_STATS flag to see this issue. > Ran graphics unit tests also and i don't see any issues with this change. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1463#issuecomment-2129398988 From kcr at openjdk.org Fri May 24 12:37:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 12:37:18 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v9] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 15:50:46 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() The latest version looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2076800098 From jvos at openjdk.org Fri May 24 12:37:20 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 24 May 2024 12:37:20 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v9] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 15:50:46 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2076803074 From jhendrikx at openjdk.org Fri May 24 13:25:11 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 24 May 2024 13:25:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <4-glKL9dec_2NpQONuXQT5R85s52eZnYiFeBXjhY7vU=.ba5fcfb5-a03b-4557-95d3-4e5a2ea619b5@github.com> On Fri, 24 May 2024 12:12:27 GMT, Kevin Rushforth wrote: > > > I wonder if we may want to add some tests for the `FixedCapacitySet`? > > > > > > Yeah, now that it is more likely that this will make it into FX, I will add a small set of unit tests for this class. > > Since this PR is ready to integrate, I think it would be fine to file a new test bug for the additional tests if you like. If you prefer to add the new tests now, that's fine, too (we can re-review it). I'm fine integrating this as-is and adding a test soon after. I will leave this over the weekend to give others time to review. Also some clarification on the contributing rules: "all Reviewers who have requested the chance to review have done so" -- does the indication at the top right of the PR count towards this or should it be a comment? :) In the first case, @nlisker and @arapte, please indicate if you wish to review this still. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2129527739 From angorya at openjdk.org Fri May 24 14:27:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 24 May 2024 14:27:12 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v9] In-Reply-To: References: Message-ID: <4u9dD2P32we6mv1YCJrHuyNaH60R6cLluS812Oh0HGk=.06a9d02f-a9ed-429f-abee-0ca97fcd33a9@github.com> On Wed, 22 May 2024 15:50:46 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1326#pullrequestreview-2077078270 From kevin.rushforth at oracle.com Fri May 24 15:02:40 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 May 2024 08:02:40 -0700 Subject: JavaFX 22.0.2 will be closed for fixes on June 10th Message-ID: All, If you have backports that you want to get into jfx22u for JavaFX 22.0.2, please do so by Monday, June 10th. Note that approval from one of the project leads is needed as outlined in this message [1]. Thanks. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-January/044659.html From nlisker at openjdk.org Fri May 24 15:07:12 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 24 May 2024 15:07:12 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff The code looks good. I didn't test it, but I'm fine with integrating. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2129765316 From kcr at openjdk.org Fri May 24 17:27:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 17:27:06 GMT Subject: Integrated: 8332732: Clean up non-standard use of /// comments in JavaFX In-Reply-To: References: Message-ID: On Thu, 23 May 2024 15:22:38 GMT, Kevin Rushforth wrote: > [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405) added markdown support to javadoc, using `///` to indicate markdown documentation comments. As a result, building JavaFX docs with JDK 23 produces new warnings, which causes the build to fail (since we treat warnings as errors). > > This PR was generated by running a program to automate the modification of each line that contains three or more slash chars in a row, `///` (except those in String literals). The replacement algorithm is as follows: > > 1. Replace each occurrence of exactly 3 slash chars `///` with 2 slash chars `//` > 2. Replace each occurrence of 4 or more slash chars with an equal number of `-` chars, leaving the first two `//` chars of the first run of `////` as is. > > This is similar to the proposed fix in java.base for [JDK-8331879](https://bugs.openjdk.org/browse/JDK-8331879) / PR openjdk/jdk#19130 (except for how I propose to handle the case of exactly three slashes). > > As an alternative approach, I could fix just the 5 javadoc comments causing the error, and leave the rest alone, but this will prevent problems from cropping up in the future, and is in keeping with changes going into the JDK source base. This pull request has now been integrated. Changeset: 31fe622c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/31fe622c4e540df06ed727343ace16cba3942534 Stats: 1309 lines in 50 files changed: 0 ins; 0 del; 1309 mod 8332732: Clean up non-standard use of /// comments in JavaFX Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1461 From angorya at openjdk.org Fri May 24 18:02:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 24 May 2024 18:02:14 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... I see a problem on Windows 11 at 125% scale: using the tester app in the ticket, the table focus rectangle's right edge is not visible at some width (i.e. appears and disappears when resizing the window width): ![Screenshot 2024-05-24 105107](https://github.com/openjdk/jfx/assets/107069028/81c57e47-9175-43c5-939a-28dd85138afd) When it is visible, there is no jitter described in the ticket. Also, it can be reproduced at 100% scale. It may or may not be a separate issue. modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java line 626: > 624: @Override > 625: public void setClipNode(NGNode clipNode) { > 626: System.out.println(clipNode); should this println be removed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2130095158 PR Review Comment: https://git.openjdk.org/jfx/pull/1462#discussion_r1613777480 From kcr at openjdk.org Fri May 24 18:05:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 18:05:09 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v4] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 14:01:40 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Implement isSizeToSceneAllowed() method to determines whether the sizeToScene() request is allowed. Implement much more tests > - Merge branch 'master' of https://github.com/openjdk/jfx into jdk-8326619-maximize-minimize-scene > - improve tests > - JDK-8326619: Improve tests > - JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window I won't have time to do a detailed review for a while, but the updated approach to the fix looks promising. I note that the change in behavior will need to be documented another way, possibly in the base `Window::sizeToScene` method, since the newly added method is, correctly, not public (nor should it be). When running the new test on macOS, I see a few test failures followed by a crash. The crash is clearly a bug in JavaFX glass code (I'll file a bug for that), but the failures point to a problem with the test. I noticed while running it that there are no delays between various window operations in the tests. This will never work on Mac (and likely is a factor in provoking the crash), and will not be reliable on other platforms. Here are the test failures: SizeToSceneTest > testInitialSizeOnSizeToScene() FAILED org.opentest4j.AssertionFailedError: 1536.0 <= 410 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageSceneBounds(SizeToSceneTest.java:77) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeOnSizeToScene(SizeToSceneTest.java:197) SizeToSceneTest > testInitialSizeSizeToSceneFullscreenOnOff() FAILED org.opentest4j.AssertionFailedError: 1536.0 <= 410 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageSceneBounds(SizeToSceneTest.java:77) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeSizeToSceneFullscreenOnOff(SizeToSceneTest.java:229) SizeToSceneTest > testInitialSizeMaximizedOnOffSizeToScene() FAILED org.opentest4j.AssertionFailedError: 1536.0 <= 410 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageSceneBounds(SizeToSceneTest.java:77) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeMaximizedOnOffSizeToScene(SizeToSceneTest.java:245) SizeToSceneTest > testInitialSizeFullscreenOnOffSizeToScene() FAILED org.opentest4j.AssertionFailedError: 1536.0 <= 410 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageSceneBounds(SizeToSceneTest.java:77) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeFullscreenOnOffSizeToScene(SizeToSceneTest.java:213) SizeToSceneTest > testInitialSizeSizeToSceneMaximizedOnOff() FAILED org.opentest4j.AssertionFailedError: 1536.0 <= 410 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageSceneBounds(SizeToSceneTest.java:77) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeSizeToSceneMaximizedOnOff(SizeToSceneTest.java:261) Java has been detached already, but someone is still trying to use it at -[GlassWindow(Overrides) windowDidResignKey:]:jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m:96 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000102f2fdbe, pid=25095, tid=259 # # JRE version: Java(TM) SE Runtime Environment (21.0.2+13) (build 21.0.2+13-LTS-58) # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.2+13-LTS-58, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64) # Problematic frame: # C [libglass.dylib+0x29dbe] -[GlassWindow(Overrides) windowDidResignKey:]+0xde # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # jfx/tests/system/hs_err_pid25095.log Gradle Test Executor 1 finished executing tests. # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # 0 libglass.dylib 0x0000000102f2fd7b -[GlassWindow(Overrides) windowDidResignKey:] + 155 1 CoreFoundation 0x00007ff807aea688 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137 2 CoreFoundation 0x00007ff807b833fe ___CFXRegistrationPost_block_invoke + 88 3 CoreFoundation 0x00007ff807b83353 _CFXRegistrationPost + 536 4 CoreFoundation 0x00007ff807abd927 _CFXNotificationPost + 729 5 Foundation 0x00007ff80892ab30 -[NSNotificationCenter postNotificationName:object:userInfo:] + 82 6 AppKit 0x00007ff80ad2bd37 -[NSWindow resignKeyWindow] + 758 7 AppKit 0x00007ff80b4d7e4b -[NSWindow _orderOut:calculatingKeyWithOptions:documentWindow:] + 326 8 AppKit 0x00007ff80abdd8b7 NSPerformVisuallyAtomicChange + 132 9 AppKit 0x00007ff80b4da0a7 -[NSWindow _reallyDoOrderWindowOutRelativeTo:] + 618 10 AppKit 0x00007ff80b4da4ca -[NSWindow _reallyDoOrderWindow:] + 99 11 AppKit 0x00007ff80b4da740 -[NSWindow _doOrderWindow:] + 295 12 AppKit 0x00007ff80b4d5029 -[NSWindow _finishClosingWindow] + 306 13 AppKit 0x00007ff80ae92a1d -[NSWindow _close] + 336 14 libglass.dylib 0x0000000102f3071f -[GlassWindow_Normal close] + 79 15 Foundation 0x00007ff8089a0743 __NSThreadPerformPerform + 177 16 CoreFoundation 0x00007ff807af4eba __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 17 CoreFoundation 0x00007ff807af4e5c __CFRunLoopDoSource0 + 157 18 CoreFoundation 0x00007ff807af4c93 __CFRunLoopDoSources0 + 311 19 CoreFoundation 0x00007ff807af38bf __CFRunLoopRun + 916 20 CoreFoundation 0x00007ff807af2ec1 CFRunLoopRunSpecific + 560 21 libjli.dylib 0x000000010201bee2 CreateExecutionEnvironment + 386 22 libjli.dylib 0x00000001020178bd JLI_Launch + 1357 23 java 0x0000000101faec17 main + 391 24 dyld 0x00007ff8076be41f start + 1903 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2130099872 From hmeda at openjdk.org Fri May 24 18:30:35 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 24 May 2024 18:30:35 GMT Subject: RFR: 8332539: Update libxml2 to 2.12.7 Message-ID: <5R2zsxrDkOKnd8f9lJKw0zhAmJUxnAid9prh-Ynsip4=.da48aa17-4890-4fd2-b79d-d5f6caf2ed7d@github.com> Updated libxml to v2.12.7. Sanity testing looks fine. No issue seen ------------- Commit messages: - configure libxml on windows - configure libxml on linux - update libxml to v2.12.7 Changes: https://git.openjdk.org/jfx/pull/1464/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1464&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332539 Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1464.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1464/head:pull/1464 PR: https://git.openjdk.org/jfx/pull/1464 From kcr at openjdk.org Fri May 24 18:30:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 18:30:35 GMT Subject: RFR: 8332539: Update libxml2 to 2.12.7 In-Reply-To: <5R2zsxrDkOKnd8f9lJKw0zhAmJUxnAid9prh-Ynsip4=.da48aa17-4890-4fd2-b79d-d5f6caf2ed7d@github.com> References: <5R2zsxrDkOKnd8f9lJKw0zhAmJUxnAid9prh-Ynsip4=.da48aa17-4890-4fd2-b79d-d5f6caf2ed7d@github.com> Message-ID: On Fri, 24 May 2024 18:18:22 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.7. Sanity testing looks fine. No issue seen Reviewers: @kevinrushforth @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1464#issuecomment-2130131350 From tsayao at openjdk.org Fri May 24 20:02:11 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 24 May 2024 20:02:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff I built it and tested on a retail self-checkout app that uses a lot of css. All good. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2130271332 From kcr at openjdk.org Fri May 24 20:25:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 May 2024 20:25:07 GMT Subject: RFR: 8332539: Update libxml2 to 2.12.7 In-Reply-To: <5R2zsxrDkOKnd8f9lJKw0zhAmJUxnAid9prh-Ynsip4=.da48aa17-4890-4fd2-b79d-d5f6caf2ed7d@github.com> References: <5R2zsxrDkOKnd8f9lJKw0zhAmJUxnAid9prh-Ynsip4=.da48aa17-4890-4fd2-b79d-d5f6caf2ed7d@github.com> Message-ID: On Fri, 24 May 2024 18:18:22 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.7. Sanity testing looks fine. No issue seen Code changes look good. Tests are green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1464#pullrequestreview-2077902852 From kcr at openjdk.org Sat May 25 13:53:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 25 May 2024 13:53:11 GMT Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <5M9fsKoLrvUOf79DR-M2FAfV1L-l-6gvu4zILkTaDJA=.5cdff5c7-8aaf-43f8-a32a-ed0a7fe678b1@github.com> On Fri, 24 May 2024 15:04:08 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move getStyleClassNames to location it was introduced to reduce diff > > The code looks good. I didn't test it, but I'm fine with integrating. > Also some clarification on the contributing rules: "all Reviewers who have requested the chance to review have done so" -- does the indication at the top right of the PR count towards this or should it be a comment? :) In the first case, @nlisker and @arapte, please indicate if you wish to review this still. If someone wants you to wait for them, they should make it clear by adding a comment. Also if someone has given substantive feedback, but hasn't (re)approved, it's good to give them a change to review. @arapte can add a comment if he wants to review, otherwise go ahead and integrate on Monday. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2131275284 From nlisker at openjdk.org Sat May 25 19:42:10 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 19:42:10 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Fri, 24 May 2024 11:18:35 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Future enhancements >> CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. >> >> In a follow-up PR, the following types will implement the `Interpolatable` interface: >> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Merge branch 'refs/heads/master' into feature/css-transitions > - extract magic string to named constant > - use existing property in test > - fixed documentation > - Merge branch 'master' into feature/css-transitions > - update 'since' tags > - Fix javadoc error > - Change javadoc comment > - Merge branch 'master' into feature/css-transitions > - Discard redundant transitions in StyleableProperty impls > - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 I did a quick review of some of the code, mostly the API. I still don't know what happens when a value is programmatically set while a css transition is in progress. What I understood is that binding the property will not allow the transition to start/continue, but didn't see where setting a value was mentioned. Otherwise looks good. I don't intend to review this beyond my current comments, so you can integrate once resolved. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 688: > 686:

Transitions

> 687:

JavaFX supports implicit transitions for properties that are styled by CSS. When a property value is > 688: changed, it smoothly transitions to the new value over a period of time. Implicit transitions are supported Maybe not so smoothly when using a step interpolator? modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 690: > 688: changed, it smoothly transitions to the new value over a period of time. Implicit transitions are supported > 689: for all primitive types, as well as for types that implement javafx.animation.Interpolatable.

> 690:

Transitions can be defined for any node in the JavaFX scene graph with the following properties:

The way this is phrased makes it sound like the node has "the following properties", not the transition. Maybe move that part: "Transitions with the following properties can be defined for any node in the JavaFX scene graph", or just add a comma. modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 40: > 38: * @param duration duration of the transition > 39: * @param delay delay after which the transition is started; if negative, the transition starts > 40: * immediately, but will appear to have begun at an earlier point in time Why accept a negative delay? An [`Animation`](https://openjfx.io/javadoc/22/javafx.graphics/javafx/animation/Animation.html#getDelay()) doesn't accept it. modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 277: > 275: * @since 23 > 276: */ > 277: public enum StepPosition { I think it would be helpful to include (or link to) images that show what the steps for each option looks like. The verbal description is a bit technical. modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 328: > 326: * @since 23 > 327: */ > 328: public static Interpolator STEPS(int intervals, StepPosition position) { Static method names shouldn't be named like constants, although `Interpolator` does this for other methods already. Not sure if this trend should continue. ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2078912077 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614833351 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614836286 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614815486 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614554508 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614789417 From nlisker at openjdk.org Sat May 25 19:42:11 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 19:42:11 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 18:10:46 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 319: >> >>> 317: * The output time value is determined by the {@link StepPosition}. >>> 318: * >>> 319: * @param intervals the number of intervals in the step interpolator >> >> minor: When I see a plural like `intervals` (or `employees`) I think of a list of objects. Perhaps `intervalCount` would be better? > > Doesn't sound better to me, but I'll defer to what most people feel is best. I somewhat agree with John. I would probably just use `numberOfIntervals`, but `intervalCount` of `numIntervals` is also fine. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614560326 From mstrauss at openjdk.org Sat May 25 20:40:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 20:40:39 GMT Subject: RFR: 8311895: CSS Transitions [v18] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Future enhancements > CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. > > In a follow-up PR, the following types will implement the `Interpolatable` interface: > `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/a43dee30..d3184e6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=16-17 Stats: 28 lines in 7 files changed: 8 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Sat May 25 20:40:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 20:40:40 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 10:40:05 GMT, Nir Lisker 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 57 commits: >> >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - extract magic string to named constant >> - use existing property in test >> - fixed documentation >> - Merge branch 'master' into feature/css-transitions >> - update 'since' tags >> - Fix javadoc error >> - Change javadoc comment >> - Merge branch 'master' into feature/css-transitions >> - Discard redundant transitions in StyleableProperty impls >> - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 277: > >> 275: * @since 23 >> 276: */ >> 277: public enum StepPosition { > > I think it would be helpful to include (or link to) images that show what the steps for each option looks like. The verbal description is a bit technical. I've included the images that are also used in the CSS reference documentation. Now there are two copies of these images in two different `doc-files` folders, but I guess that's okay. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614863775 From mstrauss at openjdk.org Sat May 25 20:43:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 20:43:12 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 17:40:01 GMT, Nir Lisker 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 57 commits: >> >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - extract magic string to named constant >> - use existing property in test >> - fixed documentation >> - Merge branch 'master' into feature/css-transitions >> - update 'since' tags >> - Fix javadoc error >> - Change javadoc comment >> - Merge branch 'master' into feature/css-transitions >> - Discard redundant transitions in StyleableProperty impls >> - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 328: > >> 326: * @since 23 >> 327: */ >> 328: public static Interpolator STEPS(int intervals, StepPosition position) { > > Static method names shouldn't be named like constants, although `Interpolator` does this for other methods already. Not sure if this trend should continue. Changed the parameter name to `intervalCount`. I agree that the uppercase naming scheme in `Interpolator` is a bit unfortunate, but at this point I think consistency is more important. We're unlikely to add more built-in interpolators in any case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614865200 From mstrauss at openjdk.org Sat May 25 20:52:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 20:52:13 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 19:28:56 GMT, Nir Lisker 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 57 commits: >> >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - extract magic string to named constant >> - use existing property in test >> - fixed documentation >> - Merge branch 'master' into feature/css-transitions >> - update 'since' tags >> - Fix javadoc error >> - Change javadoc comment >> - Merge branch 'master' into feature/css-transitions >> - Discard redundant transitions in StyleableProperty impls >> - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 688: > >> 686:

Transitions

>> 687:

JavaFX supports implicit transitions for properties that are styled by CSS. When a property value is >> 688: changed, it smoothly transitions to the new value over a period of time. Implicit transitions are supported > > Maybe not so smoothly when using a step interpolator? I've changed the wording a bit. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 40: > >> 38: * @param duration duration of the transition >> 39: * @param delay delay after which the transition is started; if negative, the transition starts >> 40: * immediately, but will appear to have begun at an earlier point in time > > Why accept a negative delay? An [`Animation`](https://openjfx.io/javadoc/22/javafx.graphics/javafx/animation/Animation.html#getDelay()) doesn't accept it. The W3C specification for the [transition-delay](https://www.w3.org/TR/css-transitions-1/#transition-delay-property) property mandates it, and this PR is a complete implementation of the specification. You're right that `Animation` doesn't support negative delays, but at least for implicit transitions, negative delays have some utility. Maye we can revisit the choice to disallow negative delays for `Animation` later. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614870557 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614870213 From nlisker at openjdk.org Sat May 25 20:52:14 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 20:52:14 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 20:37:44 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/animation/Interpolator.java line 277: >> >>> 275: * @since 23 >>> 276: */ >>> 277: public enum StepPosition { >> >> I think it would be helpful to include (or link to) images that show what the steps for each option looks like. The verbal description is a bit technical. > > I've included the images that are also used in the CSS reference documentation. Now there are two copies of these images in two different `doc-files` folders, but I guess that's okay. I think it's fine. Another option is to link to the part of the reference where they are. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614872766 From mstrauss at openjdk.org Sat May 25 21:07:11 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 21:07:11 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 19:35:56 GMT, Nir Lisker 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 57 commits: >> >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - extract magic string to named constant >> - use existing property in test >> - fixed documentation >> - Merge branch 'master' into feature/css-transitions >> - update 'since' tags >> - Fix javadoc error >> - Change javadoc comment >> - Merge branch 'master' into feature/css-transitions >> - Discard redundant transitions in StyleableProperty impls >> - ... and 47 more: https://git.openjdk.org/jfx/compare/94aa2b68...a43dee30 > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 690: > >> 688: changed, it smoothly transitions to the new value over a period of time. Implicit transitions are supported >> 689: for all primitive types, as well as for types that implement javafx.animation.Interpolatable.

>> 690:

Transitions can be defined for any node in the JavaFX scene graph with the following properties:

> > The way this is phrased makes it sound like the node has "the following properties", not the transition. Maybe move that part: > "Transitions with the following properties can be defined for any node in the JavaFX scene graph", or just add a comma. I understand that you're saying that `property`, `duration`, `timing-function`, and `delay` are all sub-properties of `transition`. However, from a CSS perspective, `transition-property`, `transition-duration`, `transition-timing-function` and `transition-delay` are properties of `Node`, in the same way as `-fx-background-color`, `-fx-background-insets`, etc. are properties of `Node`. `transition` is a short-hand property that combines all four properties into one (we don't have a short-hand property for backgrounds yet). I think that both mental models are basically correct (four properties of node, vs. four sub-properties of transition). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614886767 From nlisker at openjdk.org Sat May 25 21:16:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 21:16:08 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 21:04:24 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 690: >> >>> 688: changed, it smoothly transitions to the new value over a period of time. Implicit transitions are supported >>> 689: for all primitive types, as well as for types that implement javafx.animation.Interpolatable.

>>> 690:

Transitions can be defined for any node in the JavaFX scene graph with the following properties:

>> >> The way this is phrased makes it sound like the node has "the following properties", not the transition. Maybe move that part: >> "Transitions with the following properties can be defined for any node in the JavaFX scene graph", or just add a comma. > > I understand that you're saying that `property`, `duration`, `timing-function`, and `delay` are all sub-properties of `transition`. > > However, from a CSS perspective, `transition-property`, `transition-duration`, `transition-timing-function` and `transition-delay` are properties of `Node`, in the same way as `-fx-background-color`, `-fx-background-insets`, etc. are properties of `Node`. > > `transition` is a short-hand property that combines all four properties into one (we don't have a short-hand property for backgrounds yet). I think that both mental models are basically correct (four properties of node, vs. four sub-properties of transition). I understand. I find it a bit confusing, but OK to leave as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614892590 From mstrauss at openjdk.org Sat May 25 21:16:07 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 21:16:07 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 19:39:12 GMT, Nir Lisker wrote: > I still don't know what happens when a value is programmatically set while a css transition is in progress. What I understood is that binding the property will not allow the transition to start/continue, but didn't see where setting a value was mentioned. Any of the following actions will cancel a running transition: 1. Setting the property value 2. Binding the property 3. Making the node invisible (i.e. `isTreeVisible()` returns false) 4. Removing the node from the scene graph In effect, transitions are only active when "left alone", any programmatic interaction will cancel them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2131459204 From nlisker at openjdk.org Sat May 25 21:20:09 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 21:20:09 GMT Subject: RFR: 8311895: CSS Transitions [v18] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 20:40:39 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Future enhancements >> CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. >> >> In a follow-up PR, the following types will implement the `Interpolatable` interface: >> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > address review comments This is what I would expect, so looks good. Where is this mentioned to the user? ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2131460092 From mstrauss at openjdk.org Sat May 25 21:39:24 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 21:39:24 GMT Subject: RFR: 8311895: CSS Transitions [v19] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Future enhancements > CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. > > In a follow-up PR, the following types will implement the `Interpolatable` interface: > `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/d3184e6c..4cb6c876 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=17-18 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Sat May 25 21:39:24 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 25 May 2024 21:39:24 GMT Subject: RFR: 8311895: CSS Transitions [v18] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 21:17:06 GMT, Nir Lisker wrote: > This is what I would expect, so looks good. Where is this mentioned to the user? Good question. Since we don't have any suitable API elements for javadocs, I've added some documentation to the CSS reference. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2131488168 From nlisker at openjdk.org Sat May 25 23:22:11 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 25 May 2024 23:22:11 GMT Subject: RFR: 8311895: CSS Transitions [v19] In-Reply-To: References: Message-ID: <4r8GDJS7VcvisnsHigIbeQFbn2byTZ8pUjnX6uOXNIk=.718db671-c0b6-47ad-93ab-e8a48ecd8437@github.com> On Sat, 25 May 2024 21:39:24 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Future enhancements >> CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. >> >> In a follow-up PR, the following types will implement the `Interpolatable` interface: >> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added documentation modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 749: > 747:
  • The property value is set programmatically
  • > 748:
  • The property is bound
  • > 749:
  • The node becomes invisible
  • I would mention that this relates to the `visible` property and not to the `opacity` one (the node is invisible if opacity is 0). Other than that, looks good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1614945779 From mstrauss at openjdk.org Sun May 26 08:08:26 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 26 May 2024 08:08:26 GMT Subject: RFR: 8311895: CSS Transitions [v19] In-Reply-To: <4r8GDJS7VcvisnsHigIbeQFbn2byTZ8pUjnX6uOXNIk=.718db671-c0b6-47ad-93ab-e8a48ecd8437@github.com> References: <4r8GDJS7VcvisnsHigIbeQFbn2byTZ8pUjnX6uOXNIk=.718db671-c0b6-47ad-93ab-e8a48ecd8437@github.com> Message-ID: On Sat, 25 May 2024 23:19:03 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added documentation > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 749: > >> 747:
  • The property value is set programmatically
  • >> 748:
  • The property is bound
  • >> 749:
  • The node becomes invisible
  • > > I would mention that this relates to the `visible` property and not to the `opacity` one (the node is invisible if opacity is 0). > > Other than that, looks good. I've changed it to `The node (or any of its parents) is invisible, as indicated by the Node.visible property`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1615101199 From mstrauss at openjdk.org Sun May 26 08:08:26 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 26 May 2024 08:08:26 GMT Subject: RFR: 8311895: CSS Transitions [v20] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Future enhancements > CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. > > In a follow-up PR, the following types will implement the `Interpolatable` interface: > `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: documentation change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/4cb6c876..f64ad706 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=18-19 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From tsayao at openjdk.org Sun May 26 11:28:10 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 26 May 2024 11:28:10 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v12] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 22:02:33 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'refs/heads/master' into egl > - Use prismES2EGLX11 as build name > - Merge branch 'master' into egl > - Prefer EGL over GLX > - Merge branch 'master' into egl > - Merge branch 'master' into egl > > # Conflicts: > # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c > - Use EGL instead of GLX It seems to make a difference when display refresh rate is lower (60Hz). With higher refresh (160hz), no difference. **EGL:** ![Screenshot from 2024-05-26 08-22-04](https://github.com/openjdk/jfx/assets/30704286/325c4e49-6d45-4bd4-8ff8-2aa220d226b4) **GLX:** ![Screenshot from 2024-05-26 08-22-24](https://github.com/openjdk/jfx/assets/30704286/e5a8167a-cca9-48bc-acaa-231e07363b06) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2132184361 From nlisker at openjdk.org Sun May 26 11:29:10 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 26 May 2024 11:29:10 GMT Subject: RFR: 8311895: CSS Transitions [v20] In-Reply-To: References: Message-ID: On Sun, 26 May 2024 08:08:26 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Future enhancements >> CSS transitions requires all participating objects to implement the `Interpolatable` interface. For example, targeting `-fx-background-color` only works if all background-related objects are interpolatable: `Color`, `BackgroundFill`, and `Background`. >> >> In a follow-up PR, the following types will implement the `Interpolatable` interface: >> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`, `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`, `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`. >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > documentation change I reviewed only the API and some of the internal code. Didn't test it. Looks good. I think the CSR needs updating. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2079580350 PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2132184809 From nlisker at gmail.com Sun May 26 11:45:32 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 26 May 2024 14:45:32 +0300 Subject: CFV: New OpenJFX Reviewer: John Hendrikx In-Reply-To: References: <5cc64015-f0b3-427c-8cba-c7b2290f5e18@oracle.com> Message-ID: Resending the vote on the mailing list because I sent it only to Kevin. Vote: YES On Thu, May 23, 2024 at 2:38?AM Nir Lisker wrote: > Vote: YES > > On Thu, May 23, 2024 at 2:24?AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. >> >> John is an OpenJFX community member, who has contributed 39 commits [2] >> to OpenJFX. John regularly participates in code reviews, especially in >> the areas of JavaFX properties, scene graph and UI controls, offering >> valuable feedback. >> >> Votes are due by June 5, 2024 at 23:59 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#jhendrikx >> >> [2] >> >> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%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 mhanl at openjdk.org Sun May 26 12:34:05 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 26 May 2024 12:34:05 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: <2hw6_q5kwWxQsXh9piaaGPq0xVcPwjKWIDeV8lJZ05A=.a37f449f-dbfc-46fa-a540-34501617325b@github.com> On Fri, 24 May 2024 16:59:20 GMT, Andy Goryachev wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of JavaFX. >> ... >> I could track it down to be a typical f... > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java line 626: > >> 624: @Override >> 625: public void setClipNode(NGNode clipNode) { >> 626: System.out.println(clipNode); > > should this println be removed? yes, forgot to remove. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1462#discussion_r1615181856 From mhanl at openjdk.org Sun May 26 12:38:07 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 26 May 2024 12:38:07 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v5] In-Reply-To: References: Message-ID: On Thu, 23 May 2024 22:30:29 GMT, Andy Goryachev wrote: > with the latest monkey tester I see that updating the stylesheet does not update the showingDelay property immediately. When the tooltip gets shown, I see the following output from the change listener added to this property: > > ``` > showDelay=1000.0 ms > showDelay=100.0 ms > ``` > > I suppose the second setting of 100ms (the value I actually set) happens too late or simply is ignored. Ah, I think I know why. Same problem, we copy the stylesheet right before showing, so this is updated to late once again. We may need to do the update stuff always before showing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2132205203 From mhanl at openjdk.org Sun May 26 12:47:20 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 26 May 2024 12:47:20 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Improve test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1462/files - new: https://git.openjdk.org/jfx/pull/1462/files/9d20198f..bb27b3fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1462.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1462/head:pull/1462 PR: https://git.openjdk.org/jfx/pull/1462 From mhanl at openjdk.org Sun May 26 12:47:20 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 26 May 2024 12:47:20 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... > I see a problem on Windows 11 at 125% scale: using the tester app in the ticket, the table focus rectangle's right edge is not visible at some width (i.e. appears and disappears when resizing the window width): > It may or may not be a separate issue. Yeah this is a 'known bug' for me, and has nothing to do with this fix. Note that I only can reproduce this with 125% scale, not 100%. Windows 10 here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2132207865 From mhanl at openjdk.org Sun May 26 13:02:23 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 26 May 2024 13:02:23 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Add a test for changing the stylesheet and always process CSS for that matter ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/a3f9f609..dc24b7f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=04-05 Stats: 40 lines in 3 files changed: 27 ins; 8 del; 5 mod Patch: https:/